I Waited 10B Cycles and All I Got Was This Loading Screen
blog.preyneyv.dev
blog.preyneyv.dev
It's hard to describe because modern Excel doing typical actions doesn't feel slow and prior to this experience I would have said it was immediately responding to my inputs, but the difference experienced was obvious and felt GREAT even though it was probably only a small number of milliseconds.
Microsoft Office 2003 Standard Edition cost $400 new, or $239 per upgrade ($664 or $397 in today's money). If you wanted Excel alone, you could buy that, for $229 (or $109 if you upgrade from an earlier version). That alone would be $380/$181 in today's money.
Keep in mind that features were released every two years at the very earliest. Two years of Microsoft Teams costs $96 and gets you hosting.
The question of web vs native isn't "do you want fast software or slow software" but "do you want cheap software that brings lots of features or do you want expensive software that makes you pay again to keep up with the competition after two years".
Of course enterprise pricing was more generous and piracy was another factor that doesn't really come into play with Teams, but I'm not surprised all software has moved to quickly evolving web apps these days. In a time where paying more than $60 for a video game is considered controversial, $660 office suites simply aren't viable.
Another smaller issue with even modern Excel over old versions of Excel is that a lot of sandboxing has been added since, and even that is proving not to be sufficient by itself. The old happy-go-lucky Excels were a one-click way into infecting a whole network because no time was wasted on boundary checks where it was not absolutely necessary to prevent the program from crashing. Web apps especially have layers upon layers of security mechanisms to prevent viruses from spreading as trivially as they did twenty years ago.
In the grand scheme of things, maybe not a big deal? But that's also how things get worse.
The first was a simple Text UI for a business application. In other words forms using a text UI instead of a GUI. Underneath it was just laying out the screen with curses, and reading the keyboard, moving between fields on the form and doing basic jobs like text, number and date entry. I don't recall why we didn't use existing libraries, but it did mean we had something to compare it to. To this day remember the end result. It was blinding fast. So fast it ran far faster on a IBM PC running MMU-less Linux that any web form you'll find today. I still have no idea what the other libraries could possibly be doing to make them so slow. If you want to get a feel for the difference in todays terms, compare vim to vscode.
The other thing was a web framework. None of the other members of my team had formal programming qualifications. All of them struggled with any sort of concurrency and I found myself forever fixing race conditions in their web apps. Whenever the "run the main loop until nothing changes" nature of modern web frameworks reared it's ugly head, they were lost. So I wrote one that didn't need that loop. Instead, when you changed a property, it and everything that depended on it changed when you did the assignment, synchronously. It turned you needed so much boilerplate it was ugly to use. But again, it was fast. The first remark most people made when using a SPA based on my app was how snappy it was. Everyone touts how simple and fast their virtual DOM is, but evidently that's only in comparison to other virtual DOM's. Compare to just manipulating the real DOM once and only once for each change, they are all dog slow.
Then there is the difference between a Linux Desktop and the Windows 11 desktop. While I guess it happens less often than not, Windows 11 can take seconds to respond to a mouse click. Turns out that creates a cognitive load Windows uses seem to be unaware of. They have to constantly poll the interface to verify it's read for the next click or key press. You don't notice it until you move from a Linux windowing system to Windows. Then it's jarring, for a while.
I am hoping Vision Pro, Meta or VR / AR will finally have enough incentive to solve latency computing. Most of today's computing is very slow. From OS to Apps and Web. And I value Steve Jobs' opening the lid of a MacBook and it should be ready mentality. Sometimes I think if Steve Jobs was the yard stick on speed and smoothness of the Apple software platform. Because it has gone downhill since. Especially on Safari.
The trouble is that "fast" is an insufficient word to describe a piece of software.
As everyone has certainly realized by now, software feels "fast" when it is very responsive, e.g. the latency is low, and Sublime Text certainly felt "fast". However, Sublime Text regularly ran into problems where it had too much algorithmic complexity, e.g. when dealing with pathological cases like extremely long lines or something like that. Basic editing could become slow or you might even need to force close it. Not great.
VSCode feels reasonably responsive, at least, it certainly feels more responsive than you'd expect what is effectively a web app strapped to a browser to feel. A lot of effort was put into the feel of Monaco and keeping the text editing relatively unblocked. But maybe most importantly, careful optimization made VSCode perform well in a lot of scenarios where even native code software like Sublime and Kate struggled, with very fast Find and Replace that could gracefully handle pathological cases and a document structure that was good at loading, displaying and editing large documents (and with some limits applied to try to prevent pathological cases from blowing up the user's editor window.)
Zed is off to a good start because it takes a lot of learnings from VSCode and others. In my opinion though, it doesn't really feel dramatically better than VSCode, as the day-to-day UX is just less polished over all. It is, however, very promising, as it certainly feels better than VSCode did in the early days of it.
Most people are “okay” with waiting 500ms for a right-click context menu to appear,
I have often this debate with friends that think VSCode and co are awesome when for me it is barely usable to have an editor with so much latency on each key typed.
Same effects with apps like mail clients. When you are in Gmail and struggle to select hundreds of spam in multiple pages to delete them, compare that to the instant click/drag select of emails with infinite scrolling in native applications like thunderbird.
Do we then expect all the apps we work with to become snappy again? Or are there red-queen-like dynamics that will prevent it?
Product designers not understanding how adding certain UI elements, animations or requesting certain features is the main cause from my experience. The fastest way to speed things up in certain cases is to just remove some elements.
I would expect the situation to get worse rather than better if LLMs can deliver any feature a product designer wants without limitation and if the product designer doesn't care about "snappiness"
If you think that’s an unrealistic assumption, please feel free to propose another!
Currently designers have pretty limitless ability to add features even without LLMs. LLMs will just compound that. The only way to get efficient code is to have the right mindset from the get go. Not as an after thought that you hope the LLM will optimize.
Microsoft has enough engineer-hours on hand to make snappy UIs if they wanted to, but it's just not a priority for them. More/cheaper engineer hours doesn't really change that prioritization.
If you think there’s a more interesting/realistic/well-defined assumption, please suggest it!
I mean, we currently think in the context of programming languages as written text, but AI has shown that it's capable of doing speech-to-speech "tasks" (for lack of a better word), where tokens are not only present in the form of text tokens, but also audio tokens, which skips the TTS step. It might become able to do video-to-assembly tasks, where it sees what an electron app does, maybe also reads the code, and then knows what needs to be done to convert this into optimized assembly code.
...when it's other people's cycles & time. If Google can squeeze the last 0.1% out of their servers, they will.
But there's no incentive to make the experience better for users unless it both has a measurable impact and there's a viable competitor.
I will say I share the authors sentiment that 9 billion cycles should be enough for anybody. Unfortunately for us, it’s usually somebody else’s computer that’s holding us up.
This is a pretty canonical description of tech debt, right? "Get it working, ship it, we can worry about performance later."
https://www.youtube.com/watch?v=Ge3aKEmZcqY&list=PLEMXAbCVnm...
He also has a "performance-aware programming" series:
https://www.youtube.com/watch?v=pZ0MF1q_LUE&list=PLEMXAbCVnm...
The only thing that really bugs me computer speed wise these days is connecting to wifi. Why does that take a minute while you just want to read something?
I definitely agree with the content, though. I'm so glad I don't do webdev.
[0] I think this is actually correct usage of "ironic."
Edit: uBlock is blocking one analytics script and there are no other scripts on the page. Disabling uBlock doesn't seem to affect page behaviour.
Tauri (an electron-like written in rust) used to have a page where they touted how efficient it is, boasting that it "only" took 300mb of ram to run a “hello world” app, and it started up in only ("only") 25000 syscalls. 300mb of ram is 2.4 billion bits. Just, how? The tauri benchmarks page has since been taken down - perhaps out of embarrassment.
In comparison, the Super Nintendo had 128kb of RAM (2000x less than needed for tauri's hello world) and it ran all sorts of incredible games, including the legendary super mario bros. The Atari 2600 shipped with 128 bytes of ram, which is less than one tweet. (Though cartridges could contain extra ram chips).
The laudable terms used in the Tauri benchmark was a tad silly (though it makes some sense, as Tauri competes with Electron, not with normal native toolkits) but modern GUIs require more processing power than those 160x120 GUIs from back in the way did. It also helps a lot that you can subscribe to modern app subscriptions for half a decade before you've paid the price of what software used to cost (software that would be outdated by next year, and you had to pay again to upgrade), and that old price didn't come with hosting of any kind either.
Programmers have always been lazy, but the modern laziness when it comes to performance isn't because nobody cares; it's because nobody is willing to pay for the kind of responsiveness of yore anymore.
I use a different retro point of reference than josephg, though it happens to involve the same microprocessor. One of my favorite programs as a child was Diversi-Tune, an early music program for the Apple IIGS. It could play and record MIDI, and also show song lyrics, karaoke-style. The total program size is just under 48 KB, including one file that appears to contain configuration data. Granted, that doesn't count the Apple IIGS ROM or the ProDOS 8 operating system. When you add those, the total comes to just under 200 KB (for a ROM version 01 Apple IIGS).
And Diversi-Tune didn't even use all of the ROM. I know this because one of the areas where Diversi-Tune fell short, even by Apple IIGS standards, was accessibility. The documentation for the Textalker GS screen reader specifically called out that the screen reader didn't work with Diversi-Tune because Diversi-Tune didn't use QuickDraw II for text output. Needless to say, Diversi-Tune didn't support modern internationalization either.
But how much code would it really take to implement a modern Diversi-Tune with accessibility, internationalization, and so on? It must be well short of the ~180 MB (and growing) for an Electron binary. Current work on Rust GUIs suggests that the binary size might fall between 5 and 15 MB, depending on which compiler optimizations one chooses. And that's with an advanced GPU-based renderer that compiles shaders at run time. I'm sure it's possible to do better on that front. Of course, that's on top of the OS, but one could easily imagine a sub-500-MB Linux-based OS as the platform. I don't know about memory usage.
I downloaded it over my 56k modem and if I'm remembering right, the download was around 2-3mb.
If mIRC is all you need, mIRC still works just fine. It's still maintained, so unlike ancient versions of MS Office, you can be reasonably safe while using it!
Hundreds of megabytes is overstating it. Windows 98 was 175mb for the entire OS, including the kernel and all included applications. I doubt the windows UI library of the day (winforms, gdi, etc) totalled more than 20mb. (But please fact check!)
And, I don’t think browser engines like electron do ship their own system dlls. Dlls are only relevant on windows - they won’t do you any good on Linux or macOS. And windows always comes with those dlls. I’m pretty sure chrome on windows still makes use of a lot of the underlying windows APIs to render content on webpages in a system-native way. It just has its own layer of heavily custom UI code layered on top.
But yeah, it’s cool that applications like mirc still work. It would definitely be a fun project to make a Spotify client or something in zig using winforms. It would be a fun exercise to make something so small.
So what? None of that stuff necessitates such obnoxious computing requirements. How would you fill 2.4 billion bits of ram with the stuff needed to support a 120hz display? You can run quake 3 at 120fps on a potato, and I promise you a full multiplayer 3d game engine has much higher ram and compute requirements than a font engine with a single font loaded.
> it's because nobody is willing to pay for the kind of responsiveness of yore anymore.
Aren't they? With an attitude like that, how would you know?
Sometimes I imagine an alternate universe where computer hardware doesn't get faster every year. In this world, consumers only replace their computers and phones when they physically break. As a result, our software couldn't keep getting slower over time. Any increasing bloat & new features would usually need to be "paid for" performance wise with newly added optimisations.
For most consumers, everything would look more or less the same. All the software most people depend on (email, teams, the web, etc) would run the same as it does today. But miraculously, people would save thousands every year by getting off the computer hardware treadmill. Across the whole world, hundreds of billions of dollars per year of money spent on computers would be saved.
There's no way you could convince someone living in that alternate reality that our reality makes any amount of sense.
The cost would be that programmers would need to stop getting increasingly lazy every year. We'd just need to stop at the current laziness level. Can we manage that? Apparently not. Instead we have attitudes like yours. "My hello world app is actually similar to crysis in its computing requirements. It somehow needs 300mb of RAM to be able to render text at 120fps, because thats how that works."
If you think you can make competing software for the Teams/Slacks of this world that runs the way programs written for Windows 2000 run today by just convincing a few developers not to be lazy, you stand to make a LOT of money. I'd welcome your attempt for sure.
Everyone knows there's no strict necessity to modern desktop bloat, but nobody seems to have come up with a solution other than "what if we all did a lot more hard work (mostly for free)".
In 2021 they claimed a RAM usage on Mac OS of 13MB vs 34MB for Electron [0]. In 2022 the numbers (on Linux) were more than 10x as high, 180MB vs 462MB as well as a startup time of 0.4s vs 0.8s [1]. In 2023 the comparison is gone from the Readme.
[0] https://archive.org/details/github.com-tauri-apps-tauri_-_20...
[1] https://archive.org/details/github.com-tauri-apps-tauri_-_20...
But imagine for a moment what would happen if we had faster automobiles and shorter distances: things would just be better.