HN Explorer

Ask HN: What happened to binary sizes?

8 points by Tanegashima ↗ HN
Graphical Win 9x applications installer download sizes:

* WinAmp 2.666 = 2.1MB

* Opera 6.0 = 3.2MB

* mIRC 6.0 = 1.1MB

* WinZip 8.0 = 1.2MB

You get the idea, why today's binaries themselves are so big, and the App bundles ridiculously big too?

I see that myself, I compile simple Apps and I see the executable size, and I don't know how I could program so many megabytes!

15 comments

[ 3.1 ms ] story [ 44.7 ms ] thread
vinayan3
Well all of those examples were apps with a single target architecture, win32 or win16.

These days apps have to compile for multiple architectures especially on Android. Those are all packaged up together. Not only that these days you have multiple sizes for image assets for various pixel densities. On top of it all these days people rely on a lot of external libraries which may or may not be on a phone or system. You can't depend on shared linking like when developing for Windows back in the day.

Not to mention, fonts. Apps these days package up fonts and send them along too.

[Edited for more content]

Tanegashima
Case: eBay for iOS

.app package: 112.9MB

Excluding all the frameworks, all the graphical resources, etc.

The binary is a whopping 30.7MB

Okay that it has armv7 and armv8, then again, it's already 15 megabyte per architecture.

And the App is really simple, specially compared to a fully featured web browser like Opera!

vinayan3
It takes a bit of engineering to cut binary sizes down. It depends on how much they care and the cost they incur by having larger binaries. With building mobile apps you get a prebuilt XCode project and it takes a lot of effort to tinker with it to reduce binary size.
Tanegashima
I understand that.

But how could the executables? You know, the machine code, get so big.

And I'm comparing installers with just the app!

vinayan3
The machine code can be so big because people put huge strings as constants. As I mentioned cutting down binary size comes from working on the code and understand how the complier translate it into machine codes. The compiler could unravel a loop, inline functions, etc... The compiler is making decisions about binary size vs speed for you. There are ways to tell it not to do that.
flukus
What does the ebay app do that it needs different binaries instead of the standard <whatever an android jar> is called?
vinayan3
APK? Well he's talk about iOS even then on Android you can write native code and compile to armv7 etc... and have optimized binaries for certain CPUs.
flukus
Ah, didn't realize it was iOS, didn't know iOS ran on multiple architectures for that matter. Is there a reason (other than incompetence) they don't just publish 2 versions for the different CPU's?
Tanegashima
This is iTunes download.

When the user downloads, he downloads only the version that works with their CPU.

overint
A lot of modern desktop apps these days tend to run in electron or similar and require the overhead of large libraries/components (chromium for electron). A lot the bloat seems to come unnecessary duplication of resources, but since storage space and bandwidth is no longer as much of a premium I don't think it's much of an issue anymore.
inetknght
It is still a premium, just not to the users that these apps typically target.

I, for one, like being able to install Linux on a 4GiB thumb drive. If your app doesn't work with command line parameters without a GUI and can't be installed in spare space on a 4GiB drive then your app probably doesn't target me at all.

Note that there are a TON of apps that do fit well within those requirements.

tonyedgecombe
Bandwidth, memory and disk space are all cheap so it doesn't make much sense to optimise them.
inetknght
The resources are cheap to developers and big-name business. The resources are still not cheap to everyone else. Small businesses generally suffer pretty badly while the poor suffer the most. I know several poor families who have computers from ages ago (if any) because that's all they can afford. The computer still works for now, but it takes minutes for them to do anything, even browsing certain popular websites.

I know tons of people at small businesses who work with or on machines that are considered "new". But these new computers are as cheap as possible. $250 for a computer is amazing. Disk space is the greatest (maybe 500GB, but it's a spindle disk). RAM is starved (lucky if there's 4GB). CPU is typically, at best, a Core i3, and probably more like a Celeron, Pentium, or often AMD.

The real irony? Despite having a poor-man's CPU, its utilization is usually really low because of the amount of swapping that occurs to a spindle disk. Having superlarge pretty fancy apps (that, honestly, business users don't care about for productivity) really kills the user experience. That's, of course, assuming that the app doesn't have other shortcomings. Bugs and counter-intuitiveness really hinders things too, particularly when certain problems only show up when things run slow.

First thing I recommend to them is to invest in an SSD and some more RAM. But the $100 for that is often out of the reach of these people.

So, to reiterate: cheap resources to you doesn't mean your desired audience also considers these to cheap too.

nevon
But to be crass, does your business really care about those users? Depending on your business model and target audience, spending a bunch of resources to optimize your app in order to capture more low-income users might not make economical sense.

Even if you would like to spend that time trying to optimize your application, my experience is that it's very difficult to get the mandate to do anything beyond spending a few hours on it when you could be spending that time making some new sellable feature.

akoster
One app that keeps my faith in native binary apps is Telegram. Its iOS app is usually around 40MB and keeps compatibility with old iOS versions down to iOS 6 (as of v3.18). The desktop Qt app is also around 40MB uncompressed. On iOS, from using the app, most of the controls seem to be native and it uses minimal custom font/image resources and outside of the code to draw Qt widgets, it seems to be a similar situation on Windows. On macOS, the native (non-Qt) app clocks in at 15MB [0], which was recently re-written in Swift, likely also using mostly APIs native to the OS. Of course, not every developer has time to devote to craft such customized software to each platform, but in these cases Telegram does restore my faith that highly-efficient binaries can be built for desktop apps in 2017.

[0] https://itunes.apple.com/us/app/telegram/id747648890