Developers & Peformance: The Lies we tell ourselves

Peformance has been the goal of software since it's inception, attempting to maximize computation without sacrificing accuracy or time, decades of research has gone into this field, countless articles and books can be found detailing various methods of how to acheive this goal. Many have come and gone in this field and still we strive to acheive the most performance we can.

So why do I say we tell ourselves lies you might be asking? It's quite simple really, because in all the articles and research, a solution is yet to present itself in the ever growing field of performance research. Entire languages have been born out of the necessity of solving this problem and yet it is something we still haven't solved ? It is a lie we tell ourselves because we have lost the essence of this research in favour of language tribalism and tool mania/phobia depending on how much coffee you've had in the morning.

Language Tribalism ? WTF is That ?

Well, to put it simply in this context, it's the belief that one language or the other will truly magically improve performance and end the debates forever. Developers are quite opinionated, I would know, I writing this article, so we will never be able to agree on a language that solves all the problems because we all have the patterns we've gravitated towards. So why do we continue this endeavour ? Because everyone loves to see their favourite win, whether it be Rust or Zig or Gleam or whatever new language touts the latest ways to make all our speed problems disappear. Language tribalism pervades the entirity of developer culture and in certain ways it can't be avoided, but a certain level of objectivity is deserved by the final users of our products. Language tribalism presents itself as the primary cause of slowing down true research into actually speeding up systems. Systems are now believed to be inherently faster simply by virtue of the language they are being written in and I can tell you this first hand, while using the highly praised "Zed" editor on my 2015 HP Laptop, that this isn't the case.

Tool Mania/Phobia

This comes second because this sector has been greatly affected by language tribalism that it is almost unfair to address it on its' own but I will nonetheless because along with believing languages are the solution to our problems we have created layers upon layers of tools that will help us achieve the goal of performance, most especially in the web dev space, which I all too familiar with by virtue of my career experience. If we can just minify, ship less javascript, no-build and more and more, eventually my code will be much faster on my end-users device. Again, I can say first hand that this isn't the case

Then What is the Case ?

The case ? the case, is that there is a fundamental divide between the people doing peformance research and code optimization and the people using the software they are building/going to build/have built. This point is the crux of this article and the reason I have written it in the first place, I am hard pressed to take advice on improving performance on my software from a developer sporting the latest in Apples innovation or lack thereof or using the latest Threadripper custom PC because that is hardly my development environment and it's not the environment my end users will be on because the average person doesn't need all that power on their finger tips. I began formulating this article the day I attempted Tauri, the tool touted to be the "ElectronJS Killer" by so many across the internet for using the native webview and not shipping chrome and all the spiffy new things. You can imagine my surprise when my personal machine ground to a halt attempting the initial build. Why did it grind to a halt ? because of the sheer amount of libraries and tools that needed to be built BEFORE building my actual application, and this is AFTER it had downloaded all these libraries directly from the internet, In that moment it became clear to me that the appeal of Rust was the language and the perception of better tools, it was no different than an

npm install

after all, you just didn't have to type out npm install to use it. After many months, I revisisted this endeavour again and reached something that every new rust developer eventually reaches, JSON parsing. To my surprise, I had to add a new library to my application by configuring a toml file and running a build for that package to be added. I had to add Serde AND Serde-JSON because the Rust standard library was "light", I'd imagine JSON parsing is common place but how would I know? At this moment it crystallized for me, developers don't want to achieve performance, we want to offload it, we want to hand over the goal to a tool we've abstracted a way to never think about it again, we don't want to write the code that IS performant, we want the language to TELL US that it's performant and we're all set. We want to build in Raylib and ImGUI because we KNOW those are performant but we don't want to press the matter further. And this is just a personal development experience, not even regarding applications I've been a user of that have been touted as speedy, there are a barage of wonderful applications that I use currently that I dread to open each time because I know they will grind even my mobile phone to a halt just by opening them for a minimum of 2 minutes before I regain control of my device to acheive what I opened it to. And I can hear the camps being formed already about how it isn't a native app. I use alot of FOSS apps and I know their codebases and I simply do not care to name them because it would swiftly become attacking rather than raising criticism

Why does it matter ?

Because developers are a privileged breed, we have to recognise that at some point. We have access to the bleeding edge of technology, we build the bleeding edge of tomorrow, we can't run false bench marks against imaginary specifications with our CLI tools and upload graphs to our landing pages and convince everyone we've built performant software/hardware because everyone else deserves more than that. I consider myself privileged by many standards because there are others with worse hardware than I have and I'm on bad hardware so every app I build, I build knowing someone worse will be interested in using the application at some point and I don't want their hardware to be the reason they can't. It matters because we are arguing over the wrong things in search of our goals and irritating each other in the process when the answer has been staring us right in the face and it has for a long time.

What's the Answer

To put it short ? Effort. there, you can go, that's the answer.

But if you want more, the answer, is putting in the effort to work on our software. Testing and re-testing, in all environments and across all experiences beyond our own, it is a shame that AB-testing comes so late in a products life cycle because users have more input to give than just "how good it looks" and "how nice it feels", they can give us important information about the nature of our applications within their unique contexts that allow us build applications that feel fast not because of animation tricks but because they truly are fast.

It's the effort of building tools that are truly cross-platform instead of using the excuse of it's not native to shield ourselves from our reality. It's beyond building and rebuilding rendering engines and working towards unifying our approaches towards these problems on a human level before approaching the technology.

I think the reality of performance research is having the time and energy to run our products on the actual devices our products will eventually run on instead of simulated environments that piggyback on the RAM and Threads of our existing devices

We say that hardware has gotten better but software has gotten worse, but it's not because the languages suddenly suck or that our patterns are suddenly antiquated but because the perception that everyone is on the newest of everything and on the most powerful of devices has permeated through our culture that we don't want to put in that little bit more effort.

It truly sank in for me when a fellow developer said to me, "When you turn on a PC with an SSD and you're right back where you were in seconds instead of minutes you'll never want to go back" that I truly understood this divide and I shortly began preparing this article to share.

I laughed at myself when I initially brought up the "human level" initially, knowing myself and my hatred of crowds and general inter-personal interactions as a person on the spectrum but I have the unique experience of having this be my special interest so I have found myself uniquely capable of it, to my surprise.

This article is one I will be coming back to many times in the future to update because things WILL change and I don't intend for this document to only be a marker of where we were, but also a log book of the future we will build.