[procone]

Are you really so strapped for disk space that 70MiB impacts your user experience?

EDIT: The parent comment is disingenuous: the application isn't even 70MB. It's only 70MB if you download the windows edition with vendored libicu (unicode, 31MB) library. It weighs around ~20MB on linux distributions, which is insignificant.

[not_a_shill]

Even worse this kind of critique is actively cancerous to new developers if they actually think that people outside of HN care about this.

Development productivity over everything. Features matter not app binary size.

[Beldin]

That mindset is why modern-day ultrabooks give the same practical performance as 15 years ago. All of the hardware advances have been gobbled up in the name of "developer productivity".

Check (eg.) the Elevated 4k Demo winner to glimpse what modern computers are actually capable of in the hands of good developers.

[fluoridation]

Eh. Binary size by itself contributes very little to an application's performance.

>Check (eg.) the Elevated 4k Demo winner to glimpse what modern computers are actually capable of in the hands of good developers.

If all software were to be built using the same techniques the demo scene uses, nothing would ever get done, and if by chance a project does get released, no one would be able to maintain it afterwards. Let's not confuse art and engineering just because both use code as the medium.

[dicytea]

An application's performance is orthogonal to its binary size.

[GuB-42]

Not orthogonal, maybe diagonal.

Sizecoding productions are an exception, because they tend to use really slow and memory hungry unpackers (can take up to gigabytes of RAM to do their job, for a 4k intro!), and they tend to lack all optimization techniques that could improve speed in exchange for more code (ex: culling, etc...). And flooding memory with millions of generated objects is no problem for these productions, as long as they are not stored in the executable.

But in general, larger binaries are slower to load, simply because there is more bytes to copy from disk to RAM. And although it is not always the case (ex: sizecoding), it usually means a larger memory footprint, resulting in worse CPU cache efficiency, less memory for other apps and filesystem caches, etc... Also, large binaries tend to be a symptom of inefficient code, with too many abstraction layers, poor optimization, etc... Another very common reasons for bloated executables is that they bundle all their libraries, which means that they don't take advantage of shared libraries, requiring the OS to maintain multiple copies of the same library, possibly including some outdated or poorly optimized versions.

[integricho]

I don't agree with this, not by a long shot, this kind of mindset is why we have such a cancerous proliferation of overbloated and slow software today and it's just getting worse and worse every day.

[not_a_shill]

So what? The tradeoff is that you make much less money with your mindset in exchange for impressing people on an internet forum.

[myankoo]

> Features matter not app binary size.

*.exe in Everything = 11 586 objects on this machine.

At 70MB a piece that would come out to ~800GB.

[wander_homer]

If you'd be running Qalculate on a Linux desktop system, where all the "heavy" dependencies (ICU, GTK or Qt) are already present and shared between all applications, Qalculate wouldn't require 70MB.

Of course you could also provide a Win32 frontend to bring down the space requirements drastically and make it more Windows "native"; there's a well documented libqalculate for exactly those purposes.