6 ms·

SizeBench: A new tool for analyzing Windows binary size

51 points by GordonS 5y ago

steeve 5y ago
A famous one is Google's Bloaty McBloatface [1]. It's a very powerful and useful tool. 1. https://github.com/google/bloaty https://github.com/google/bloaty
- mwcampbell 5y ago
  How is bloaty's Windows support? One thing I like about bloaty compared to SizeBench is that the former is a CLI tool.
5- 5y ago
from the linked microsoft store page, https://www.microsoft.com/en-us/p/sizebench/9ndf4n1wg7d6 https://www.microsoft.com/en-us/p/sizebench/9ndf4n1wg7d6: Approximate size: 276 MB looks like they should try running this tool on itself?
- mwcampbell 5y ago
  It's a .NET application using WPF, with the CLR bundled, as is the norm for .NET Core. The fact that the developers of SizeBench chose not to value small size above all else in the tool itself doesn't invalidate the work they've done on what looks like a useful tool.
  - userbinator 5y ago
    It's still incredibly ironic and a bit WTF. For contrast, the old WinDirStat disk space visualisation utility is a single binary around 600KB. Not tiny, but not elephantine either.
    - zamadatix 5y ago
      I always liked Diskitude which was a 10k single binary, even supports hidpi! Author did go to town on the optimization though, it doesn't even use the c std library.
      - 5- 5y ago
        that's pretty good! the equivalent on my system is a monster of more than 5x the size: $ yay -Qi xdiskusage|grep Size Installed Size : 54.77 KiB > it doesn't even use the c std library. isn't that expected of win32 applications? {kernel,user}32.dll typically provide the equivalent functionality.
        zamadatix 5y ago
        Typically applications still use some part of the c stdlib even if they use win32. In particular the diskitude site notes some of the math stuff took extra work.
    - contextfree 5y ago
      Presumably that utility depended on OS APIs and libraries, though? My guess is this app would probably have been similarly small or at least much smaller if it had used a systemwide installed framework (i.e., Win32, systemwide .NET Framework, or System XAML/UWP) instead of bundling its own. But that approach is out of fashion because app and framework developers don't want to be tied to the OS, have to wait for their users to upgrade their OS before anyone can use new features, be tied to the OS support lifecycle, deal with compatibility issues and dependency conflicts, etc.
- userbinator 5y ago
  That's... wow. A full install of Windows 95 with Office 95 is smaller than that.
com2kid 5y ago
> I started developing SizeBench during the Windows Phone days mostly out of curiosity – my team had a bunch of code, and a bunch of bytes ended up on disk, but I couldn’t figure out the relationship between the two. I asked around for tools to help with that but sadly found none, so I figured I could try to build one. He should have asked me, I did a lot of thiswhile I was on the Windows Phone compiler team! :-D I spent a lot of time with dumpbin, learning how to find inefficiencies or even outright code generation bugs in the ARM compiler. My best find was 14 extra bytes inserted after every function, IIRC it was originally to work around a bug on MIPS16 but it ended up getting added to code generation across all platforms. It is nice someone has improved dumpbin and added some more features, and a nice UI. "New hire in office looking at object file dumps" wasn't really scalable, though I did my best!
mwcampbell 5y ago
Damn, wish I'd known about this while I was on the Windows accessibility team at Microsoft (mid 2017 to late 2020). I even used to work in the same building as Austin. Then again, if I'm honest, I would only have used this tool to waste time satisfying idle curiosity; I was never specifically tasked with reducing binary size.
herf 5y ago
One thing here is that it suggests removing pure virtual functions with just one implementation. I use this pattern often to kill dependencies, say when one huge part of an app needs to call another one, but you don't want to create a dependency one way or the other. In C++, compile times sometimes explode if you include every header in every other one - so it's really great when you can #include just a one-line generic "virtual" callback interface from two places instead. But yes it affects binary size just a bit.

51 points by GordonS 5y ago

A famous one is Google's Bloaty McBloatface [1]. It's a very powerful and useful tool. 1. https://github.com/google/bloaty https://github.com/google/bloaty

mwcampbell 5y ago
How is bloaty's Windows support? One thing I like about bloaty compared to SizeBench is that the former is a CLI tool.

5- 5y ago

from the linked microsoft store page, https://www.microsoft.com/en-us/p/sizebench/9ndf4n1wg7d6 https://www.microsoft.com/en-us/p/sizebench/9ndf4n1wg7d6: Approximate size: 276 MB looks like they should try running this tool on itself?

mwcampbell 5y ago
It's a .NET application using WPF, with the CLR bundled, as is the norm for .NET Core. The fact that the developers of SizeBench chose not to value small size above all else in the tool itself doesn't invalidate the work they've done on what looks like a useful tool.
- userbinator 5y ago
  It's still incredibly ironic and a bit WTF. For contrast, the old WinDirStat disk space visualisation utility is a single binary around 600KB. Not tiny, but not elephantine either.
  - zamadatix 5y ago
    I always liked Diskitude which was a 10k single binary, even supports hidpi! Author did go to town on the optimization though, it doesn't even use the c std library.
    - 5- 5y ago
      that's pretty good! the equivalent on my system is a monster of more than 5x the size: $ yay -Qi xdiskusage|grep Size Installed Size : 54.77 KiB > it doesn't even use the c std library. isn't that expected of win32 applications? {kernel,user}32.dll typically provide the equivalent functionality.
      - zamadatix 5y ago
        Typically applications still use some part of the c stdlib even if they use win32. In particular the diskitude site notes some of the math stuff took extra work.
  - contextfree 5y ago
    Presumably that utility depended on OS APIs and libraries, though? My guess is this app would probably have been similarly small or at least much smaller if it had used a systemwide installed framework (i.e., Win32, systemwide .NET Framework, or System XAML/UWP) instead of bundling its own. But that approach is out of fashion because app and framework developers don't want to be tied to the OS, have to wait for their users to upgrade their OS before anyone can use new features, be tied to the OS support lifecycle, deal with compatibility issues and dependency conflicts, etc.
userbinator 5y ago
That's... wow. A full install of Windows 95 with Office 95 is smaller than that.

com2kid 5y ago

> I started developing SizeBench during the Windows Phone days mostly out of curiosity – my team had a bunch of code, and a bunch of bytes ended up on disk, but I couldn’t figure out the relationship between the two. I asked around for tools to help with that but sadly found none, so I figured I could try to build one. He should have asked me, I did a lot of thiswhile I was on the Windows Phone compiler team! :-D I spent a lot of time with dumpbin, learning how to find inefficiencies or even outright code generation bugs in the ARM compiler. My best find was 14 extra bytes inserted after every function, IIRC it was originally to work around a bug on MIPS16 but it ended up getting added to code generation across all platforms. It is nice someone has improved dumpbin and added some more features, and a nice UI. "New hire in office looking at object file dumps" wasn't really scalable, though I did my best!

mwcampbell 5y ago

Damn, wish I'd known about this while I was on the Windows accessibility team at Microsoft (mid 2017 to late 2020). I even used to work in the same building as Austin. Then again, if I'm honest, I would only have used this tool to waste time satisfying idle curiosity; I was never specifically tasked with reducing binary size.

herf 5y ago

One thing here is that it suggests removing pure virtual functions with just one implementation. I use this pattern often to kill dependencies, say when one huge part of an app needs to call another one, but you don't want to create a dependency one way or the other. In C++, compile times sometimes explode if you include every header in every other one - so it's really great when you can #include just a one-line generic "virtual" callback interface from two places instead. But yes it affects binary size just a bit.