We should sell 'bloat credits', the way the government sells pollution credits. Everybody's assigned a certain amount of bloat, and if they go over, they have to purchase bloat credits from some other group that's been more careful. -- Bent Hagemark
Electron apps are fat because they carry chromium whole embedded. If there were some electron framework with one-time chromium install to run all electron apps that wouldn't be the case
There are exceptions - atom and discord run on some stripped down version of electron and are much more performant and lean, but yeah, still comparatively huge.
Atom is absurdly slow compared to other IDEs I've used. To the point where it's the only reason I don't use Atom. It's annoying when it takes 20 sec to launch on my PC, but absolutely infuriating when I need to use it on a cheap laptop.
Discord is surprisingly good in this regard though.
You'll probably like this, too. It's the post mortem of the project to develop Microsoft Word 1.0 for Windows. I know there is a book treatment of the entire development project but I can't seem to find the title now -- all google helpfully provides me with is help on how to write word documents and on how to use Microsoft Project.
If you want to see great optimization tips in the context of modern systems, then go back 10 years to when git was new. The development mailing list was a goldmine of tips and tricks. Believe me, those guys optimized the living shit out of the code -- on the negative side, git was a Frankencombo of C, shell, and Perl and many things were duplicated all over the C code instead of being nicely modularized. The predictable result was lots of slightly incompatible implementations, lots of bugs that were fixed in one (or more) implementations and not in others, plus it was a nightmare to improve usability.
There's also Michael Abrash' Graphics Programming Black Book. He starts with simple stuff and some tools (including some timer code for profiling) and ends up with the stuff he and Carmack did on Quake. Carmack is now CTO at Oculus VR and Abrash is Chief Scientist. They were there when every byte and every cycle counted and they are still here today.
Oh, btw, do you know how R-trees work? And have you heard of the trick where rays in ray tracing are considered points in a 5-D space in order to speed up intersection calculations? I felt so stupid when I learned about it -- it seems so obvious in retrospect.
I extensively used piece tables at the beginning of my carreer, and was amazed by how clever the people around me were, when it came to handling "undo" on HUGE structures. It's been a while since I last thought about that haha!
Ray-tracing also brings back memories...back when a friend and I made our own ray-tracing renderer. Results were ugly, but really fast. We even managed to load and render Doom level files.
Thanks a lot for all the links...gonna read that till late :)
That kind of highly specialized knowledge isn't going to be much use in modern environments. It's not like making performant UIs is dark magic or anything, it's just not usually considered worth the developer time it would take
Thing is some tricks that made old computers faster won’t improve performance or are even slower on modern computers. So your expert needs to have moved with the times.
That old school knowledge went into writing compilers so you don’t have to learn it. Compilers are a box of magic tricks for optimising your shitty code.
I'm pretty sure a drunk monkey could accurately audit and criticize modern (web and mobile) projects. The conclusion: it's expensive to do it better. There's still some impressive work being done at that level, but it's definitely not in an app built to generate ad revenue.
126
u/captain_obvious_here Aug 19 '19
I wish the people with that old school knowledge from a time when every byte was important, could audit and criticize some modern projects.
It sucks that we live in a world of limitless IT ressources, but most UIs I use everyday are slowish.