While many people copy and paste unoriginal thoughts about AI and the so-called “vibe coding”, it seems that what used to make software valuable is constantly put aside. If you try to argue that tech does matter in a tech-oriented product, they will tell you that:
- Business is more important than engineering
- Software is useless if it doesn’t make money
- Users only care about features
- Devices are powerful, performance doesn’t matter
- Internet is fast, a few more GBs won’t hurt
And many more dumb takes. This is the typical mentality by which consultancy firms produce the most mediocre products you will ever find.
I don’t want to delve into this endless – and hopeless – topic. Instead, I want to tell you a little story of how easy it is to lose control of software performance, and how the understanding of programming fundamentals keeps us in touch with reality. This has never been more important with the fast-paced opportunities that LLMs offer today.
Can you afford low performance?
I’m far from being a low-level programmer, yet I know C and the fundamentals of how things happen below the code.
Passepartout is a networking app mostly dealing with VPN connections. At least in the tunnel context, performance does matter. When it comes to OpenVPN in particular, it’s very hard to compete with a pure C codebase – the official library – when you also have to account for the overhead of the Swift runtime. Let’s not forget about the strict memory limits of Network Extension either. The time I spent on profiling to improve efficiency, resolve memory leaks, and reduce the crash rate, among other things, is pretty massive.
Two months ago, a user reported a regression in the OpenVPN negotiation where the handshake would never complete. I could implement a fix quickly, yet the handshake took 4x longer than with the obsolete TunnelKit. A whopping and unacceptable 20-25s vs 5s negotiation!
The domino effect of bad choices
I inspected the negotiation steps carefully for bottlenecks:
- Loops
- Blocking code
- Slow I/O
- Disputed locks
- Wrong artificial delays
- Parsing
- …and whatnot!
Now, if your life as a programmer only revolved around high-level languages like JavaScript, Python, or even Swift, you will have a hard time realizing the time cost – not the O(n) cost – of your code. Similar to how knowing SQL helps immensely when profiling a slow ORM, knowing C helps you spot poor performance in high-level programs, even if you never get to write C code.
It took me 1-2 days to realize that the culprit was ironically where I expected it the least. The performance hit was caused by the parser of the PUSH_REPLY message, which is a short comma-separated string. To be fair, the parser is quite basic, so it wasn’t the parser either: the problem was about re-creating the NSRegularExpression objects every time a new PUSH_REPLY was parsed.
Of course, it doesn’t take a lot to create an NSRegularExpression but the user’s server sent dozens of PUSH_REPLY messages to the client, so the slow code was adding up very quickly. Run a 100ms vs 500ms code once and it will be okay, but run it 20 times and you easily get a 2 seconds vs 10 seconds delay. In the vast majority of servers, the PUSH_REPLY is a single message, which made the nasty issue unnoticeable to most.
By then, I realized how too much OOP makes us programmers forget that even creating objects may be expensive. Imagine what AI can do without a supervisor. When performance is crucial, we should remind ourselves that the convenient, good-looking solution might be the worse choice.
What “vibe coders” may not be ready for
Before anything, ask yourself what your business is about. If you work at Netflix, or in the game industry, you might observe the immediate effect of an inefficient vibe-coded algorithm. In the trivial CRUD apps that make up 99.9% of the consultancy workforce, instead, you may only realize that your code has low performance after a long chain of bad choices, if ever.
Performance, however, is just an example of what’s being overseen due to the increasingly fast pace at which people produce code.
This leads to a few observations:
- If your software is “stupid”, low performance may only be hidden and therefore not seem a big deal.
- Engineers who underestimate the importance of performant solutions, probably never worked on challenging projects.
- If performance doesn’t matter to you today, it doesn’t mean it’s not important in general. Or, that it won’t be important when your business scales up.
When that day comes, will you have the knowledge you need to face it?