5 ms·
Not to criticise the application, but how realistic is that such an application weighs ~70MB?
by integricho 3y ago
Not to criticise the application, but how realistic is that such an application weighs ~70MB?
- procone 3y agoAre 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 3y agoEven 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.
- integricho 3y agoI 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 3y agoSo what? The tradeoff is that you make much less money with your mindset in exchange for impressing people on an internet forum.
- Beldin 3y agoThat 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.
- deleted 3y ago[deleted]
- fluoridation 3y agoEh. 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 3y agoAn application's performance is orthogonal to its binary size.
- GuB-42 3y agoNot 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.
- myankoo 3y ago> 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 3y agoIf 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.
- baal80spam 3y agoI knew it would be fairly big but 70MB is ridiculous. I weep for today's software.
- pantalaimon 3y agoqalculate-gtk is 3.7M on my system with libqalculate.so.22.17.4 weighing in at 5.7M
- dist-epoch 3y agoImagine if it was implemented in Electron, not in Qt. It would have been 300MB+ then.
- FreeFull 3y agoLooking at qalculate in Arch repos, libqalculate comes in at 14.94 MiB, and qalculate-qt at 3.37MiB, so 18.3 MiB total. If you're looking at the Appimage, the rest of the size would be from the libraries it depends on, like Qt/GTK+
- wffurr 3y agoSo a smallish C++ static binary then.
- Cloudef 3y agoYou took my words
- Aardwolf 3y agolibqalculate is the mathematics part and the command line tool, while qt is GUI, so it's surprising the GUI part isn't the larger one of the two
- FreeFull 3y agoAbout 6MB of it is the libqalculate.so.22.19.0 file, 1340KiB is .xml files that define all the units/functions/etc, and another 6MB is the documentation.
- eviks 3y agooh, it's way more than that, on a Mac via brew it needs 600M QT and 50M gtk+3 and a couple of dozen M for other dependencies
- mappu 3y agoI think the real issue here is the brew formula - the Qt runtime should be under 50MB (over if you include the chromium packages). Only the full development toolchain might be close to 600M and that clearly isn't needed here,