> "the software has become bloated"

Casey Muratori has a 20 minute talk on YouTube called "Clean code, horrible performance"[1]. Using an oft-repeated example in C++ he rewrites it uncleanly and then benchmarks.

Removing Classes/subclasses/polymorphism: 1.5x faster. That overhead was like reducing an iPhone 14 to an iPhone 11 performance.

Replacing Encapsulation with a table-driven calculation: 10x faster. That overhead was like reverting an average desktop CPU from 2023 back to 2010 performance.

Adding basic SIMD: 20x faster.

His position is that the principles of Clean Code wiped out 15 - 20 years of hardware progress, for a subjective ideal of maintainability, and even if they deliver on that, the cost is too high. It shouldn't/cannot cost a decade of hardware performance to make programmer's lives easier.

[1] https://www.youtube.com/watch?v=tD5NrevFtbU

While I agree with a lot of what he says (complexity and layers of abstraction impact performance), it's probably worth noting that his examples are not necessarily relevant to all software.

Does my web browser feel slow because of pointer indirection or virtual function calls? Or is it because I have to download 15 MB of Javascript to load this page, which then goes out to 35 other domains to fetch other Javascript and ads and CSS?

In the insanely tight compute loop that he's looking at all of those things definitely make a difference, but a lot of software is slow not because it's inefficiently written (which it probably is) but because it's inefficiently designed and it's doing too much.

In a game engine, where you have 16ms to do 100% of your simulation work, update all your state, and then send all the data out to be rendered, definitely this sort of thing is an issue. In an Electron app? There are a thousand other things that are wasting far more of your time and responsiveness than the misguided 'cleanliness' of your code.

Counterpoint. I have a Dell laptop from 2017 at work. I keep it around for plugging in to network equipment and that sort of thing. I've had Win 11 on it for the last few years, and it was getting unusably slow. Also, the battery, even though replaced in the last year, would only last about an hour of normal use. I had a similar belief about browsers and the web. No matter how light your OS, the browser and web experience is the bottleneck. But then a couple weeks ago, I installed Arch and IceWM with Firefox. What a difference. The thing is snappy, even in the browser. And the battery lasts all day. I was blown away.

Did the same in 2012 with hp 2510p that had windows vista pre installed on it. I could literally brew a cup of coffee and make it halfway through while this poor boy was booting up.

Bit the bullet, installed arch and dwm. I remember my initial impressions on how fast the boot went, how silent the hdd is, how the whole things works reporting just a fraction of RAM in use(right after boot).

It was the first hands-on YAGNI experience. Windows(and macos and the likes of ubuntu) loads and starts everything it has and keeps the system busy at all times in terms of cpu, disk io, network io.

Barebone linux without beefy desktop environment was like “I boot into essentials and will lazy load anything upon request”.

Exactly this. It's the design and architecture where the bloat is. Not the need for some microoptimization..

The video is exactly about design and architecture and not even slightly about microoptimization. How do you have it completely inverted?

I write clean code with lots of encapsulation. Not C++ just an ecomm webapp but our business hinges heavily on time to load and we do great there.

Clean code or messy code the thing that all fast code has in common - including your example is this: YOU FOCUSED ON IT.

You measured it, then improved against the benchmark. You spent time and effort on it so it improved.

That's it. That's the secret.

I object on a few fronts.

One is that the rewrite has 'mechanical sympathy' with the machine e.g. arrays without pointer chasing can fit more data in CPU cache with fewer stalls while it reads over the main memory bus and waits after every item. That should not be a surprise, it's knowable in advance. Why deliberately ignore knowledge about the machine when designing the code, then come back and use that knowledge?

Another objection is to the idea of "measure then improve". Imagine a delivery truck which loads parcels without checking their weight first, then drives the truck onto a weigh machine (profiling), then if the truck is overweight they unload each parcel, weigh them individually, find the one heavy one filled with lead weights, then repack the truck without it. That would be silly and inefficient, right? Now imagine they unload the truck and there's no single parcel which is surprisingly heavy and instead the goods have been packed with 'lead foam'. Who could forsee that would cause problems with the weight on the delivery truck? (Anyone!). Now what's the fix? Unpack and repack every parcel, rewrite the whole code. There's no accidentally quadratic here to remove, instead every tiny piece takes a few more microseconds than it needs to and those add up.

Another objection is "YOU FOCUSED ON IT' - this implies that there is some way you can design and write code that doesn't need any focus. Part of the point of the video is that the faster code is not harder to write, there's no complex algorithms, no compiler intrinsics, no deep knowledge; it doesn't take a focused performance expert to write a switch(){} instead of a subclass.

Another objection is your implication that performance shouldn't be a consideration until you measure it and find a problem, and prove that it is. Which is like saying that aeroplane design weight doesn't matter until after you build it and measure it and prove that it matters. Computers are finite and limited, why have we got to the stage of assuming they are infinite and unlimited, and then demanding proof that they aren't, over and over on a case-by-case basis? A 3D game can render a virtual world at 100 frames per second. Does a program which takes 3 seconds to show a username/password login prompt need enough resources for 300 frames of game until proven otherwise?

Another objection is that you are defaulting to 'clean code is the default, performant code needs measuring and benchmarking to justify itself in every individual case. Why isn't that the other way around? Less resource-wasting code as the default, and 'clean code' only when maintainability has been measured and proved to be a problem, and only in the parts of the codebase which have the highest maintainability problems?

If all the clean code, encapsulation, isolation, abstraction layers, are providing the developer benefits that are claimed - why aren't programs better? If it's now so clean and easy to refactor, why doesn't that translate to software that gets better instead of software that gets worse? Casey's example is that Visual Studio debugger updated the watch window in realtime while stepping through code, on single core Pentium 4 with 512MB RAM, and now on a modern multicore machine with 64GB RAM and an M2 SSD it can't do that. (RemedyBG can, so it's not impossible).

Another small objection that I just remembered, Casey has an interview with Rico Mariani[1] who worked on performance at Microsoft for two decades, from their first C++ compiler, to .NET, to web browsers.

He coined the phrase "pit of success" after his team had spent months profiling and tuning the .NET startup to remove many milliseconds from it. One developer on another team called a default constructor for an XML class, and in that commit wiped out all their gains, three times over, he didn't know the default path was slow and there was another way. Rico was giving a talk and said that isn't a good way to design things, success can't be the hard way that only a few experts can find, it has to be like 'falling into a pit', the default way to do things has to be the good way.

Anyway, with one browser related performance regression, they profiled and found that the layout engine was using a lot more CPU. He believed the layout engine was good enough, looked elsewhere and found a commit which invalidated a node in a tree and all subnodes. That was cheap and didn't stand out in the trace, but far away in the codebase it triggered a lot of layout updates. Separating things out to focus on just one part at a time, and then the profiler can reveal where the problems are, neither of those things worked as intended.

[1] https://www.youtube.com/watch?v=48Rig6v-xYU

Not to forget the fact that websites nowadays can be real memory hogs, are dynamically assembled on your machine and burn cycles on pure eye candy UX like animations and transparency. The web's focus on design and cleverness over content and functionality is partly to blame.

n=1 but my macbook pro constantly runs out of hard disk and memory and the two biggest culprits are jira/confluence/docs and other web apps (like 1gb+ of real memory consumed by a single instance), and the other is dev tools which litters my disk with 100s of gb of caches...

its crazy how our devices have become basically dumping grounds for terribly optimized software

Yes, but that's a game developers perspective. Hardware performance is not be-all end-all (an argument can be made on environmental reasons that it should be - but bear with me in the first instance).

Software is a tool working within a socio-technical system. Some systems have low user workflow diversity and a low rate of change - a game being a perfect example. Games get patched, but the diversity is purely in user data, not in feature use - everyone uses the same engine, the same textures, the same game logic. Some systems have high user workflow diversity - such as business software.

Pair that with the fact that games, due to the nature of the system, have to optimise for low latency AND they run on the edge - and it's natural that the primary optimisation will be for CPU cycles. For business software, for which distributional advantage of running it through web + the high rate of feature change that is a result of the specification being opaque and a moving target - means you have plenty networking latency that can hide your CPU latency for long after it becomes a true problem for you.

Not to mention that "clean code" optimises for developer churn and business priority shift (which is a luxury games which are an upfront investement don't have) as a result of accelerating industry of software technology and greater saturation of developers.

Had software remained the domain of the same number of practitioners such as <1995, even given everything else, the organisational systems would have evolved to protect them at all cost because churn would be catastrophic, and then they would enjoy more power and would be able to structure code not optimising for brain shift, because they'd hold the context in their heads.

I'll leave as exercise for the reader what pushing AI into the software development equation does for the system and inevitable hardware throughput implications.

> "you have plenty networking latency that can hide your CPU latency"

Does this excuse making 75 network calls instead of 5? Or knowing that you make a lot of network calls but designing the code as if they were instant and have the bandwidth of a local SSD?

> "Not to mention that "clean code" optimises for developer churn" "structure code not optimising for brain shift, because they'd hold the context in their heads."

Based on what studies or evidence is this optimised or optimal? How is it easier to work through code which is atomised and abstracted until there appears to be nowhere that anything actually happens, where the method and variable and parameter names are long compound words, where everything is multiple layers of indirection and generalised, and you have to hold all that context in your head?

1/ network calls are what I find still gets optimised by grouping API requests and bloating the exchange contract; but yes, if you're strictly clean coding, this will suffer too - it just happens less often than what the author of the youtube video objects to

2/ That's a fair challenge - and I definitely have more trouble reading through an absolutely ramped to the max collection of C# code (which reinforces the behaviour you describe) than a superscript; but for interchangeability, the middle between those two ends is typically better - you're trying to minimise functional context for the thing that a software developer needs to do. This has the additional failure mode that the feature that is envisioned (of sufficient complexity) never actually gets delivered, but the component parts that can be well encapsulated do. And this is because no one holds the full system in their heads. But this can be explained away to business as "there's too much complexity, we need another cycle" and "we need to iterate" and therefore the cycle continues.

I think I actually convinced myself away from encapsulation and separation of concerns in that last comment.

To be fair, Objective C uses message passing, which doesn't have the same performance characteristics as C++ (worse initially dealing with the selector pool rather than a vtable offset; much better later when maintaining stability in your brittle C++ ABI requires pImpl->pImpl patterns jumping all around heap memory).

it is interesting how the early iphone got such good performance and low memory usage with objective-c compared to android (java)

My problem with Casey is that he is not a performance engineer, he is a performance maximalist. Software is a set of tradeoffs. If he truly cared about performance, the best thing for him to do would be to write clean code that had good performance, but he refuses to do that, since it's hard. Instead he insists that the only way to do performance is to write unmaintainable code which ironically enough makes it difficult to do performance optimizations because it's hard to lean on abstractions that allow for things to be refactored.

> he insists that the only way to do performance is to write unmaintainable code

This is new to me, where does he say this specifically?

Not to white knight Casey but his niche has been in rendering and graphics afaik , where everything he does have to fit inbetween frames, so it makes sense to be a "performance maximalist" in that environment.

It could be that you and he are working on different sets of problems with different tools.

But I'd be really interested I where he says you must write unmaintainable code.

Also (my take) : if you're looking at "clean code" to find abstractions that allow things to be refactored, then I think that's probably not the type of performance he's talking about for you. LLMs can do that type of work. FWIW I think he refactors from what things ought to be, not how they are currently

Obviously he's not going to call his own code unmaintainable, but he's basically against abstractions which let people write software that needs to survive past a frame. BTW I have found that LLMs are kind of bad at doing refactoring (like, they can mechanically do a refactor, but they cannot actually help you with picking what refactor you'd want to do)

That is not my memory at all. I remember him saying to not do all of the things but just do some of them & we will all be much better off.

I have found these same principles to be true in my own projects. More modern, “cleaner” implementations usually end up with a larger code base but a noticeable reduction in performance. Bloat ruins everything.

Yeah, I think they can be a combination of processor, GPU, memory architecture, and G(UI) software.

But I too have ran a super snappy XFCE desktop for ages on pretty old hardware. I only recently switched to KDE+Wayland on much newer hardware and felt like it was snappy enough to not bother me.

I also remember there were times were my much more powerful dedicated GPU was outperformed by my CPU integrated GPU, which I think has something to do how shared memory can be faster for UI rendering (or maybe it was just driver-related)

> But the software has become bloated to the point that you need to run the latest generation of CPUs such that things are not sluggish.

As the old saying goes what Intel giveth the Microsoft taketh away.

What Andy (Grove) giveth, Bill (Gates) taketh away.

Yeah... my solution for the last 3 decades (with a grain of salt) has been to buy the most expensive decked out Apple laptop every 6 years and never, ever update the OS. This is in line with my philosophy about shoes: I only own 5 copies of one pair (4 in boxes in my closet until I wear the current ones out). Rolling everything over to a new dev environment every 6 years is annoying but manageable. This way I took a Powerbook 3400 into the intel age, took a titanium macbook into the air age, took two airs for almost a decade from 10.4 to 10.10 or something, then an M1. Which I'm still using. The 3400 still boots into OS 9 or something. I feel like I'm forgetting one. But the point is this: Apple software usually suits the hardware it's released with, and taking their updates is always a bad idea. Just get comfy with homebrew and settle down for your 30s or 40s until you've broken all the keys and the fan stops working. A $3-4k investment in the best performing machine they have will be great essentially until the machine itself breaks as long as you scrupulously block all apple ip addresses and rip all their update shit out as soon as you get your hands on it.

Also, the m5 mac mini impulse buy as a home server has been fantastic to just login to remotely, but I'm so glad I'm still using Monterey on my M1 for daily coding.

Surely you mean you don't update the major OS version, e.g. from Sequoia (15) to Tahoe (26)? Or do you literally mean if you start on Sequoia 15.0, you stay on 15.0 the entire life of the machine? The former is fairly understandable, but the latter is just insane considering the number of bugs in a x.0 release (including severe security and usability issues).

I do this! Interesting to see someone else advocating the practice. In my open source development I start work on a retro machine running Snow Leopard, specifically to be able to generate authentic retro binaries that'll work anywhere, and then I have a process to port to modern MacOS and signed Apple Silicon binaries, but the machine's a M1 Studio on Monterey and building for 11.1.

My worry is that they'll kill signing for people who aren't updating, though that shouldn't be a factor. I would have to simply get another machine to port to, because I don't trust that changes they make are always going to be good in any sense.

There might be a window for computing within which it's good: I find I'm not worried about adding new Linux machines and architectures to build for, but my Windows builds are 32 and 64 bit on Windows 7 with no attempt to modernize the build system, and I've got that two-stage Mac build process where it starts on a time capsule machine not connected to the internet, and continues on the M1 running Monterey. I'm anxious for the day Apple requires you use stuff that's constantly changed out from under you. I don't work like that.

Wow! Great respect to how you've set up your publishing that way! I don't build anything for the Apple ecosystem, and haven't since around 2015, and my biggest fear was always some dreaded forced update (or new app store jargon) .... so yeah, I think you're living on the knife's edge, but I would do the same.

One great reason for never upgrading the OS is you can still pop open a laptop and run things you wrote 10 or 20 years ago... and honestly now I've sent Claude around my local network accessing those old laptops and snapshotting and clicking ancient apps and rewriting things I'm too tired to do by hand, which is weird but kind of a nice coda to my work.

> never, ever update the OS.

> took two airs for almost a decade from 10.4 to 10.10 or something

I’m curious, did macOS 10.4->10.10 not constitute an OS update? Or was this a time when you applied your rule differently?

I'd have to check em, it was just a guess, but I have two airs from the last decade (2009 and 2015 I think) with their original operating systems and I think one is around 10.4 and the other 10.10ish.

Maybe I misunderstood your question... I never updated the OS on either of them. Or on any Mac I've owned since the mid 90s.

Oh I see, it was two different laptops, one with 10.4 and the other with 10.10.

I thought that both started at 10.4 and then had all version updates up until 10.10.

I'm not sure either of your approaches are optimal. You'd be further ahead with the shoes to be alternating two pairs as they last longer with recovery & dry time. Ignoring security updates, while maintaining performance, takes on a certain amount of risk. And while I do a similar approach to machines I do art/performance stuff with, they're air gapped when frozen. And you can't take this approach if you're publishing anything with Xcode.

I should have done this with my 2020 Intel Macbook Pro. Now it's basically unusable and spins rainbow wheels constantly, because the OS is apparently garbage for an Intel system.

I had the same experience as you. I bought a super-fast 10-core iMac 27” with 72 GB of RAM in 2020. It ran beautifully until the moment I “upgraded” to Tahoe, when it instantly became unusably slow.

This cost me half a day wiping the disk, restoring the original OS, and then carefully upgrading back to Sequoia. Now it works well again, but I am counting the days to when Linux is the only way to continue using this great piece of hardware.

Another anecdote: a few years ago I was offered a shiny new never-before-used iPad for free by a client (a telco). There was only one catch, I was told: it was a few generations old. It had sat in its box on a shelf unopened for several years. I thought it might be useful at least as an e-reader, but I soon realized why it was now useless: I could not find a single app in the App Store that would install on it because every app required a “newer OS” (which wasn’t available). Most websites also refused to talk to its old (non-upgradable) web browser. Well played, Apple.

I have an old laptop that is still usable because I never updated it from win7 or better I updated it once but switched back.

I keep thinking this and maybe I'm missing something, but I'd love to be able to opt for something in this direction, some old school constraints, I feel like we should be able to do something pretty magical these days

For example, is there a version of linux that I'm missing? I've not run a desktop linux box in over a decade, any suggestions would be great, or is everyone happily running ubuntu / fedora?

Just run debian + xfce, that’ll feel super snappy on 4GB of RAM, maybe even 2 (but then of course you’re bound by whatever other apps you use)

Plain Kubuntu on an Asus Zenbook OLED 14 laptop looks and feels pretty great compared to both Win11 on the same machine (ok that's not really surprising) or current macOS on an M1 Pro MBP (hardware is pretty old by now ofc). Once you start CPU intensive tasks the ASUS gets pretty hot though, while the Mac at most gets a bit warm.

Distro choice mostly determines package manager and how configuration works and what you get by default. Any distribution can approximately run any program and that includes window managers.

I'm using ArchLinux with XMonad as my window manager. That's neat, though it doesn't make Firefox or VSCode any faster (nor slower).

Atomic OS images. I moved away from individual package management once I discovered the alternates. Currently on Bluefin (Fedora-based) - not affiliated with the project but just a happy user.

https://projectbluefin.io/

No distro is going to be perceptibly faster than another. It's all about user experience - what tools ship with it, package manager, etc.

I'd pump the brakes on Ubuntu, which nowadays is a perceptibly worse user experience than other mainstream distros. Snap is a disaster, and flatpak rocketed past it years ago thanks to Valve bucks.

Use Debian. It's matured perfectly as a graphical distro IMO

Yeah mine is Debian + xfce although my laptop is fairly powerful 32Gb gen 12 Intel. It's fast, light and pleasure to use. Apt any day over all those fancy flat pack etc

Fedora is very good these days.

Tbh, Ubuntu/Kubuntu is fine if you're not a Linux die hard and just need a balanced OS that either feels more like macOS (in that case go for vanilla Ubuntu) or like Windows (in that case go for Kubuntu).

Ubuntu is even more problematic for non-Linux die hards because they won't know (or want to) deal with all the issues with snap (like slow app startups and other compatibility issues), or the inevitable package conflicts or other issues when it's time to do a dist-upgrade. See: https://news.ycombinator.com/item?id=42949222

My mum was on an Ubuntu base as well (Mint first, later Xubuntu) but after both eventually experienced failed dist-upgrades (no GUI after reboot), I switched her to an immutable distro (Aurora) and it's been rock solid so far. And in the event something does break, rollback is as simple as selecting the previous image from the boot menu.

So for normies who want a macOS like experience, I'd recommend Bluefin, and for Windows-like, I'd recommend Aurora. And Bazzite for gamers. All of these are Fedora-based immutable distros and have none of the stability issues that Ubuntu-based distros have, plus the generally newer kernel+mesa stack compared to Ubuntu means you'll also have better compatibility with newer hardware.

> In principle you don't need 32-core GHz CPUs to move a window around on a screen without it feeling sluggish

I think the snappiness is less this, and more about the speed to open a file, how quickly chrome pops open when you open it etc. I assume this is a combination of hardware and how fast SSD->RAM is due to the SOC, but software will certinaly play a big part too.

> I assume this is a combination of hardware and how fast SSD->RAM is due to the SOC, but software will certinaly play a big part too.

That is exactly what I'm talking about. Sorry, you are completely off. My machine 20 years ago was not an SOC and didn't have an SSD either. It was fast as lightning to open a window.

What does this have to do with SSD? Or an SOC? It's all because the software is incredibly bloated, and as your comment indicates, the young generation doesn't even know this and thinks the hardware is to blame because it's 2 gens behind state of the art (so, 3.5 years old).

This is very sad and exactly why things are the way they are.

> My machine 20 years ago was not an SOC and didn't have an SSD either. It was fast as lightning to open a window.

I never understand what people exactly mean by claims like this. I very vividly remember double clicking some executable, and then immediately hearing the HDD start to spin, and waiting with baited breath to see if it will spawn a window or silently fail, as programs on Windows 98 (the only option for personal computers at the time) often did.

So what exactly was snappy? Nothing that runs off a HDD is ever snappy.

> I very vividly remember double clicking some executable, and then immediately hearing the HDD start to spin,

Are you sure about that? At that time, hard drives were constantly spinning. Getting them to suspend was a rare feat.

> programs on Windows 98 (the only option for personal computers at the time) often did.

20 years ago, Windows 98 had long been abandoned. At that time I had been running a Linux desktop for many years already.

> Nothing that runs off a HDD is ever snappy.

Of course it can be. By already being in RAM. Open another window of some program didn't need to touch the HDD. If I nowadays open another instance of some electron thing, it takes a while load those gigabytes of bloat and make dozens of network roundtrips.

I'm not saying all software 20 years ago was snappy. But today's bloat is undeniable. The user experience has not improved with the orders of magnitude (!) with which the hardware has gotten more performant.

I think people don't realize how much more performant today's hardware is. Mostly because the bloated and terribly architected software eats it all up.

> Are you sure about that? At that time, hard drives were constantly spinning. Getting them to suspend was a rare feat.

I am pretty sure, though, of course, memory is highly fallible (and note that I was a kid back then, and didn't understand that well what those sounds or the blinking disk light actually meant).

> 20 years ago, Windows 98 had long been abandoned. At that time I had been running a Linux desktop for many years already.

20 years ago means the mid-to-late nineties. That's my position and I'm sticking with it /s

But I think it's undeniable that Linux in the 2000s was a massive pain for anyone but the most dedicated tinker, and even then only for pretty carefully chosen hardware. The Year of the Linux Desktop meme existed for a very clear reason. Virtually the entire PC user base, both Consumer and Corporate, was running Windows XP in the 2000s.

Yes! And all the splash screens!

Or even just the computer taking 5 minutes to start up.

> Sorry, you are completely off. My machine 20 years ago was not an SOC and didn't have an SSD either. It was fast as lightning to open a window.

On my machine 20 years ago most apps had some sort of loading splash screen, so I think you just have rose tinted glasses imo!

You don’t really get those anymore - you click and the app is open.

> Aren't these properties of the (G)UI rather than of the processor?

They are a result of all of them.

Yes, even my 2013 Haswell-based Arch Linux KDE Desktop feels more responsive than my M4 MacBook. And I think the MacBook has so much more power under the hood, but somehow the animation settings or whatever are just not that good.

To be completely fair, I use the Desktop via DisplayPort at 144 Hz, while the MacBook uses HDMI + USB-C, and I believe it's just at 60 Hz, which is also a factor, but I honestly think that this is not the primary reason.

I have in my basement a PC with Windows 98 that feels way faster using it than a modern Windows 11 full of vibecoded AI slop features.

Windows 11 isn’t full of vibe coded AI slop because that hasn’t existed long enough to affect it much. It is full of poor decisions and poor programming the old fashioned hand made way.

This applies to the whole stack, even ignoring the GUI, you would not find systems with a gazillion of processes, doing OS IPC all over the place, because the hardware could not accommodate it.

But hey, microservices and static linking are the future. /s

> But hey, microservices and static linking are the future. /s

Aren't those two things contradicting each other? ;)

I think macOS getting more sluggish in each release (which is objectively true) is just plain old bad software engineering and prioritising the wrong things. E.g. it's just Apple's version of "What Andy giveth, Bill taketh away.".

It's maybe a combination of incentives. Give the devs the latest shiniest model, give them a list of barely manageable feature requests , and nobody will spend the time to consider performance issues that you'd get on hardware from 10 years ago if you take approach X, Y, Z if you don't notice a difference on your formula 1 setup.

Not at all, how do you think The Network is the Computer was achieved before dynamic linking became widespread?

It's the property of the display refresh rate.

A high refresh rate is only a crutch/workaround to reduce latency caused by too many pipeline stages until an input action shows up on the screen. A better fix is too reduce complexity in the involved software layers.