[HN Gopher] SizeBench: A new tool for analyzing Windows binary size
___________________________________________________________________
SizeBench: A new tool for analyzing Windows binary size
Author : GordonS
Score : 36 points
Date : 2021-11-01 15:25 UTC (7 hours ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| 5- wrote:
| from the linked microsoft store page,
| https://www.microsoft.com/en-us/p/sizebench/9ndf4n1wg7d6:
| Approximate size: 276 MB
|
| looks like they should try running this tool on itself?
| userbinator wrote:
| That's... wow. A full install of Windows 95 with Office 95 is
| smaller than that.
| mwcampbell wrote:
| 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 wrote:
| 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 wrote:
| 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- wrote:
| 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 wrote:
| 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 wrote:
| 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.
| steeve wrote:
| A famous one is Google's Bloaty McBloatface [1]. It's a very
| powerful and useful tool.
|
| 1. https://github.com/google/bloaty
| mwcampbell wrote:
| How is bloaty's Windows support? One thing I like about bloaty
| compared to SizeBench is that the former is a CLI tool.
| com2kid wrote:
| > 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 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2021-11-01 23:02 UTC)