> 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!
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.
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.
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.
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.
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.
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.
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.
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!