PSA: Computers are Fast, Computers are Slow, A Look at Poor Software I have Written

Recently, when uploading a video to YouTube I saw an interview with game designer and programmer Jonathan Blow. I haven’t watched past the first few minutes, but he makes a very common argument that the hardware computers run on these days is insanely fast compared to where they were in the 80’s or even the 90’s. However, the software that runs on them is often so terrible that the user experience is inexplicably terrible. It reminded me of another talk he gave half a decade ago where he used Photoshop to make this very same point.

Photoshop takes seven seconds just to open itself and display an image, despite running on a modern fast SSD and a CPU that is running presumably at 4GHz, and is capable of 4 instructions per second. So, somehow, it takes 112 billion CPU instructions just to open an image. For comparison, Windows Photo Viewer can open itself, then load in the biggest images on my computer, decompress them, and display them in less than a tenth of a second. Once the program is up and running I can hit the arrow keys to go to different pictures, and it instantaneously loads them in, decompresses them, and renders them to the screen. Of course by instantaneous I mean “done within the time window of a single frame of rendering”.

Photoshop was presumptuous enough to make itself the default image on his machine when installed, which is another annoyance of modern software, although at least a fixable one. But it’s not just that it takes forever to open up images. It also takes about a second to just open up a fairly simple menu. 

Making this even more ridiculous, photoshop 6, from the year 2000, is something Blow claims to have used extensively two decades ago, or seventeen years ago when the talk was given. It has an almost identical UI and relevant features, and had to run on CPUs that were much greater than an order of magnitude slower, ditto for the hard drives of the time whichever way you measure their performance. If this version of Photoshop, which effectively just does the same things, was running on those computers it would have been unusable.

Photoshop is probably not even the best example of absurdly slow software, but I wanted to give an example of my own to show just how terrible software like this can come into existence. I had a website prior to Hyphen Report and Daily Rake. I had misread that WordPress the domain provider was censoring everyone as WordPress the technology backend was censoring everyone, so I built an extremely simple website from scratch. The frontpage of the site was some very minor decoration, and then a link to every single article I ever wrote for the site, all right there on the front page in an image -> text link format.

Despite me throwing hundreds of small images on the frontpage with accompanying text, the page loaded almost instantly. To test this I even fired up a new browser with a VPN, and the page was all there within much less than half a second, indicating that most of the wait time was unavoidable connection latency. Of course it’s perfectly reasonable for some sites to take longer to load, especially if they have things going on with the backend, but the internet is a lot faster than most people realize. 

The opposite experience occurred on that very same old site of mine after clicking on any particular article. It would initially load instantaneously, but then it would “snap” to it’s final form, which had block indents for quotations. In this case a picture is worth a thousand words.

Initial page.

The articles were written on the backend with lots of keywords thrown in. I did this because I didn’t want to have to write <div class = “quotesegment”…> followed up by </div> manually every time.

Final page after javascript.

Later a javascript program would come through and convert it to what you see above. The program was dirt simple. Just find and replace the TDC_ARTICLE_START and _STOP blurbs with the respective html. And while these articles were often fairly long, this should have been instantaneous for modern CPUs. Instead it took close to a second, or even more than a second for the longer articles.

First of all, this should all have been done offline. Since the pages were always changed in the same way it didn’t need to be done in real time, so the time this should have taken ought to have been zero. But I was lazy and didn’t want to write another program to automatically do that when I uploaded the page.  Even with javascript doing this after the user loaded the page, this should still have been effectively instantaneous. After all, we are changing a very small amount of text.

What should have happened is we do a pass through the html text, count up the additional characters required, create a new text array of the correct size, and then copy the old array of characters into the new array, replacing only the parts that needed to be replaced. The text is a few dozen kilobytes in total. We’re replacing a few dozen characters. This should have taken microseconds. Instead it can take over a full second to do, easily a thousand times longer than necessary.

For the record, you can do exactly this anytime you’d like in any text editor of your choice. Simply copy a segment of text, and then paste it over a small section of other text. You will notice that your text editor will do this instantly, because of course it will. You can even use the “find and replace,” or “ctrl + h” in most editors, to do this for lots of text at the same time. What you will notice is that your computer does not grind to a halt for many seconds while your CPU chugs through the Herculean task of editing a small amount of text. 

I’m still not sure why this copy-replace took so outrageously long. I know that every time it encounters a sub-string to replace it copies and pastes the rest of the string to a new string. This is not the ideal method, but it should also only take a few times longer than the fastest way, due to the additional copying and memory allocations. I think somewhere along the way there have to be some nested loops, or the copying is done with a new memory allocation per character. Maybe behind the scenes javascript has an array of individual strings per character or something crazy like that. It’s not really clear what’s going on, only that it’s absurdly slow. 

I have an excuse of course, in that my site was seen by almost no one and I’m not a web developer. The point I wanted to show is that I have firsthand experience with software running many orders of magnitude slower than it ought to in order to do a task that should have been done offline in the first place. This is what people like Jon Blow mean when they say that some software is running orders of magnitude slower than it ought to. It’s a real thing that happens when you have shoddy engineering, often running overtop other poorly engineered “solutions,” and the web is famous for these shifting sands of barely working software that is so far removed from the performance of the hardware it’s running on that you get these many orders of magnitude slowdowns taken as par for the course.

Yes, I am not a great web engineer, but neither are the “diverse” genderwarriors these tech corporations hire to make up their engineering departments. People who can barely get something to work are not going to be writing software that runs fast, and as a result you see this shoddy engineering and general slowness all the time with the modern computer experience. The computers get fast, and the software gets slow. Except that single threaded performance, and even GPU performance, isn’t getting that much faster these days.

I’m not going to go out on a limb predicting that we’re going to reach a situation where the software we use gets slower and slower and slower until it eventually stops working. But I’m not staking my reputation on everything being nice and peachy either. The ability to make snappy running software is dying, only a few people seem the slightest bit concerned about this, and it’s an underrated aspect of our civilizational decline.