4 ms·

so an incalculable effort was spent making chromium just tolerable, but rest assured, still far far far from any kind of random native application, in both spee

so an incalculable effort was spent making chromium just tolerable, but rest assured, still far far far from any kind of random native application, in both speed and memory usage. simply opening a chromium tab with an empty html page uses more ram than my amiga had 30 years ago, and funnily enough, I was able to run applications on that maybe i will be impressed if they manage to get the chromium abomination down to a more reasonable size, compared to its 1.7GB compressed size the source is now (how is it even possible?????).. I wonder, how big was khtml when webkit forked? how big was webkit when google forked? this shit is totally out of control, and pretending anything else is something that is quite a feat to do with a straight face, and for that, you have my admiration

cmrdporcupine 3y ago
I too from from that era of computing. That ship has sailed. There is no comparison in terms of the architectural complexity between then and now. You can decry all the layers of abstraction, and they have indeed brought amplification on the amount of memory and cycles necessary to do "simple" tasks. But they've also brought with them capabilities so far beyond what we did then. I worked in the Chromium source tree. It is indeed massive and complicated. But I can assure you that none of us were ever "wooo let's just chew memory and CPU cycles" -- it is written with efficiency in mind all over. It's just cumulatively quite complicated what it is doing. Can you write a GUI toolkit which throws away 99% of that cruft? Yes. But it will lack so many creature comforts that we've become used to. What we had back then.. it lacked vector fonts, it lacked GPU acceleration, it lacked transparencies, it lacked multiple DPI support, aliasing, subpixel rendering, etc.. It lacked accessibility. It lacked multiple keyboard layout support. It lacked proper multiple language support, it all predated unicode and nobody even thought about right to left text flow, etc.. Obviously no touch screen and gesture support. Hell, the Amiga widget kits barely had standardized components of much variety at all. And that's not even bringing up the VM that runs JavaScript. Which you can bitch all you want about it -- but back then many of us salivated over Smalltalk-80 (another garbage collected dynamic late-bound OO language) but our machines could not handle it. Turns out to do that kind of system well and at scale, you need resources far beyond 80s and 90s computers. We're there now, but it took a long time. All of this costs in software complexity. Finally, memory usage is also a lot more complicated than it used to be. Firstly, we have so much more of it than before so we can do a lot more trading off memory for speed than we did back then, when memory was stupidly expensive. Secondly, buffer management and allocation can have all sorts of subtleties esp in the context of virtual memory. Something can show in top as using X memory, but the actual mount of memory pages in physical use and currently paged into the application may not be anywhere close to that. In a virtual memory system, memory accounting is a tricky subject. Shit is not out of control. It's just a lot more complicated on the surface than you're willing to admit.
- redeeman 3y ago
  the khtml to webkit to chromium expansion is NOT in any way defensible in contrast to amount of features. I sincerely hope that it is done due to not caring even the tiniest amount about efficiency, because the alternative is not pleasant to think about. funnily enough some software cares greatly about efficiency, namely those where it isnt just possible to buy a bigger cpu and more ram to make it "tolerable", they manage to care about practically every single instruction, and what do we get for it? great quality of software

cmrdporcupine 3y ago

I too from from that era of computing. That ship has sailed. There is no comparison in terms of the architectural complexity between then and now. You can decry all the layers of abstraction, and they have indeed brought amplification on the amount of memory and cycles necessary to do "simple" tasks. But they've also brought with them capabilities so far beyond what we did then. I worked in the Chromium source tree. It is indeed massive and complicated. But I can assure you that none of us were ever "wooo let's just chew memory and CPU cycles" -- it is written with efficiency in mind all over. It's just cumulatively quite complicated what it is doing. Can you write a GUI toolkit which throws away 99% of that cruft? Yes. But it will lack so many creature comforts that we've become used to. What we had back then.. it lacked vector fonts, it lacked GPU acceleration, it lacked transparencies, it lacked multiple DPI support, aliasing, subpixel rendering, etc.. It lacked accessibility. It lacked multiple keyboard layout support. It lacked proper multiple language support, it all predated unicode and nobody even thought about right to left text flow, etc.. Obviously no touch screen and gesture support. Hell, the Amiga widget kits barely had standardized components of much variety at all. And that's not even bringing up the VM that runs JavaScript. Which you can bitch all you want about it -- but back then many of us salivated over Smalltalk-80 (another garbage collected dynamic late-bound OO language) but our machines could not handle it. Turns out to do that kind of system well and at scale, you need resources far beyond 80s and 90s computers. We're there now, but it took a long time. All of this costs in software complexity. Finally, memory usage is also a lot more complicated than it used to be. Firstly, we have so much more of it than before so we can do a lot more trading off memory for speed than we did back then, when memory was stupidly expensive. Secondly, buffer management and allocation can have all sorts of subtleties esp in the context of virtual memory. Something can show in top as using X memory, but the actual mount of memory pages in physical use and currently paged into the application may not be anywhere close to that. In a virtual memory system, memory accounting is a tricky subject. Shit is not out of control. It's just a lot more complicated on the surface than you're willing to admit.

redeeman 3y ago
the khtml to webkit to chromium expansion is NOT in any way defensible in contrast to amount of features. I sincerely hope that it is done due to not caring even the tiniest amount about efficiency, because the alternative is not pleasant to think about. funnily enough some software cares greatly about efficiency, namely those where it isnt just possible to buy a bigger cpu and more ram to make it "tolerable", they manage to care about practically every single instruction, and what do we get for it? great quality of software