Why software feels slow

Originally published at: https://boingboing.net/2018/11/22/why-software-feels-slow.html


We need to build software like they used to build pinball machines. (This is a topic I’ve written about before.)

In a pinball machine, players need the flippers to respond nearly instantaneously to the press of the button. Furthermore, they need consistency: if the latency between the button press and the flipper moving is usually fast but occasionally slow, that can be as bad as always being slow.

The inconsistency in the latency can be due to the scanning cycles talked about in the article.

Pinball machines solved this by wiring the flipper buttons directly to the actuators. Your button press (in most classic machines but not in the most recent ones) didn’t have to be periodically polled by a processor which then ran a few instructions to determine whether the flippers should be active (e.g., is the ball in play? has the player tilted the game? etc.) before setting a signal on an output line that would be detected by the next scan of the solenoid driver.

It’s like a reflex: The stimulus doesn’t need to travel to the brain and back before the muscles start to react.

A command button on a GUI should have a way to reflexively react to the finger tap or mouse click that doesn’t have to circumnavigate the entire general purpose framework. Obviously everything can’t be a reflex, but the graphical and tactile response to the stimulus could be. And should be.


A pinball machine has the luxury of always being a pinball machine, with hardwired controls. It’s never a pinball machine and a Ms Pacman at the same time, and doesn’t have to worry about Galaga trying to steal their high scores. :grin:

That said, I think the byzantine frameworks, byte code virtual machines, just-in-time compilers, languages that hide a lot of overhead are the elephant snail in the room.


News at 7 - water is wet.

1 Like

“I still fervently believe that the only way to make software secure, reliable, and fast is to make it small. Fight features.” ~ Andrew Tanenbaum


Web pages that load a bunch of crap the user doesn’t want. I wonder if we could think of an example? I know most of you guys proudly avoid the BB main page, but it is one of the ugliest and slowest pages I visit. I do it because I loathe secret club-like behavior (so I am not going to be using some insider only way of viewing BB) and also want to support BB in the simplest way available. It can be infuriating.


The arcane and esoteric secret of bookmarking the main forum page?


Relevant, and maddening to realize that computers from 1977 remain far faster than computers today in terms of latency:

Computer latency: 1977-2017

Keyboard Latency

And one more for good measure:
Terminal Latency


Here’s my secret :

Just bookmark that. I was mad when they made the format switch but this is preferable if you just want to see the posts chronologically and catch up like the old days.


Interesting but the application impact was just glossed over and that’s pretty damn critical. The chart at the end assumed every aspect of the pipeline was mutually exclusive which doesn’t need to be the case. No real consideration was made for the OS itself which could be slowing things down for any number of reasons.

Either way, it’s complicated.

What doesn’t help is the modern trend of developers simply not giving a shit about things like memory use and disk use. Modern computers have tons of memory and disk space, right? I’ll just spin up more threads and solve everything! In general it seems like unless enough people start complaining, little attention is paid to optimizations. Or they just assume they know better than the smart people that wrote the frameworks and tools they are using and roll their own.

Except these things are important and when you have a system filled running app after app where no considerations are made for optimizing resource consumption, you end up with a slow ass computer.


There’s a Main page!?


Back in the days of 300 and 1200 bps modems EMACS optimized using a special mode that told the I/O controller to echo visible characters and only transmit when the user typed a control character. This let the user type with low latency while the data was sent to the computer in the background. Once the user hit delete, return or some other control character - and EMACS has lots of those - the user had to wait for a bit. This wasn’t too bad for delete or carriage return. People used to typewriters considered a delete key to be magic. You didn’t have to get out the white tape or white liquid and fuss. That meant serious latency, especially if you had to wait for the white liquid to dry. Carriage return was similar. Mechanical typewriters, even electric ones, had a massive latency while the platen slid back and advanced the paper.

I’m not sure how much latency could be improved using similar techniques today. Obviously, browsers could note link and button presses more quickly, but other interactions are trickier to optimize.


Allegedly. It’s spoken of sometimes in hushed and haunted tones by old regulars who’ve come into contact with travelers from the Surface World. They say it’s home to monsters with mouths for eyes and side-loads gifs with strange epileptic powers and ads for twisted blunts.


Is app latency a thing that’s taught in schools? Probably not, as most of the coders who wrote the snappy software for the 8-bit machines were self-taught.


But if I go there will I be forced to RTFA before I TL;DR? Too many acronyms slow down a girl’s reactions and I need to be quick to outrun the old-school trolls and not get distracted by moving ad slideshows for things I never browsed for!


In my opinion, user interaction, either user input or feedback to user input, should always have preference over anything else for a personal computer. The users should always be able to decide what’s more important to them. Waiting for the computer to be done with some other task before it reacts to your input is infuriating.



“Yes I know you are tied up threshing about between disk and memory because I clicked a button I didn’t mean to but if you’d JUST FUCKING LET ME CLICK THE ONE I DID WANT TO it could all end now and we’d all be happy. BUT NO - you HAVE TO complete this dumb thing first. What? That’s not how computers work, you say?”

Fucking computers, how DO they work?


Yes. I think the basic problem here is that people keep making updates and adding features, rather than taking the time to make software well and fix bugs. I’d rather have the features we had ten years ago, always working and responding immediately, than any new features that have been added since then.

My general thought is that, if you can’t guarantee it will never freeze, even for a couple seconds, it shouldn’t have a GUI. Keep it as a command line function.


Um… it feels slow because it is slow?

Also, I think this is a good opportunity to recycle an old chestnut:
Cycles? Cycles are an excuse for programmers to wear lycra.

1 Like

Stop spreading urban myths.