Abstraction vs Transformation

Frequently in software development, efficiency and performance concerns weigh heavily on my mind. As a programmer deeply immersed in different languages, I've encountered my fair share of performance challenges when attempting to scale my code against ever-growing data sets. I have come to see creating abstractions can and frequently does mask implementation details that massively degrades performance.

One particularly frustrating experience is fresh in my mind: a seemingly innocuous performance issue that eluded resolution for far longer than it should have.

The culprit? Multiple layers of abstraction obfuscating a simple task: transforming a list. My "real life" example was from C++, I was going to have and example here however it sparked quite a lot of debate and anger between my 4 blog readers, so i'll retract it.

This ordeal underscored a critical truth: while programming abstractions are touted as the solution to complex problems, they can often obscure the underlying simplicity of the task at hand, leading to suboptimal performance outcomes. Conversely, embracing data transformations can offer a more efficient and effective approach to getting the work done.

Abstractions allow "humans" to reason about code and present a neater view of the problem, they hide the complexities behind a thin verneer of an API while ensureing that the compiler and runtime take the performance hit during build and run time.

Yehonathan Sharvit talks about using data as the focal point of an application in his book data oriented programming. I think he's on to a good point although he doesn't go far enough.

Unfortunately Yehonathan has a fair share of detractors that miss the point, because they are entrapped by their own thought process. To quote Morpheus from the matrix:

'You have to understand. Most people are not ready to be unplugged. And many of them are so inured and so hopelessly dependent on the system that they will fight to protect it.'

The logic is undeniable though:

• any instruction executed require a resource (memory, disk, cpu, etc)
• Abstractions require execution resources (same above)
• Transformations of ANY KIND require execution time and memory.

Therefore:

Used Resource = Abstraction Resources + Transformation Resources

will always be greater than

Used Resource = Transformation Resource.

Most people will say that making life easier for the programmer should be the primary design concern of programming. I hear CPU is cheap, disk is cheap, all hardware is cheap, while this is true it is great until it isn't. Layers of abstractions present 'simple' view but a tightly coupled 'data to class' performance profile.

Eventually, we as a profession will need to understand that hardware has limitations and has -very- specific performance characteristics that can be exploited.

The "Higher up" the abstractions are, the less likely native hardware features will be used. Compilers at the moment are simply not clever enough. Maybe one day, AI will allow this kind of magic, but not yet.

If your abstraction does not offer the abiltiy to view or execute code to specifically take advantage of hardware features, the performant code/features will be abstracted away and the benefit lost.

Software abstractions are designed to optimize for human cognition, not hardware execution. They allow us to reason about complex systems without getting bogged down in register management or memory layouts. However, every layer of indirection, virtual machine, a heavy ORM, or a "clean" architectural wrapper—introduces a performance tax.

Sometimes the abstraction tax is almost unmeasureable; other times, it requires a full audit of your system’s resources to really understand.