As software developers, we all dream of writing perfect code. A piece of code that still works after 20 years and is still actively in use. Here at OMP, we have some absolute coding gems. But the passage of time is cruel and, as code gets covered in layers of dust, you may need to do an update. And that’s when you find out if you’re dealing with a real diamond or a fake.
A very elegant reporting module was one such gem. It could take any data and carry out deft transformations, outputting a new table-like structure that could be visualized in a UI. We wrote this module about 25 years ago. Or, more accurately, it was one of my colleagues — I was not old enough to be legally working back then. That was when Netscape was popular and computers had hard drives of no more than a couple of gigabytes for the complete system.
Back then, the code was state-of-the-art. But as time went by, we added a lot of other functionality to our application, including better reporting, such as pivots and chart views. Our gem was no longer useful for graphical reports but it did become an important cornerstone for interfacing with other applications.
Because interfaces run during the night, how well the module performed wasn’t that important anymore and, when feeding more data into it, calculation times began to stretch to several minutes — and later to hours — even with faster computers. But we didn’t need to care about that because it ran during the night and those nights were long enough.
With the arrival of new requirements, our gem got reused for making interactive interfacing. As a result, its performance became much more important. It wasn’t long before I was assigned the job of making the program run faster, because who wants to wait for hours for a result after pressing the button?
But guess what: I was shocked when I looked at the code. Being familiar with the latest C++ standard, I was used to seeing vectors, unique pointers, lambdas, and standard C++ algorithms. Instead, this code was a relic, it had barely been touched in the last 20 years. It was pure C code, using all the constructs we now avoid in modern programming.
Before dealing with the problem at hand, the code needed to be modernized. Without that, the risk of introducing new issues was just too great. Diving into the code, I recognized some concepts and replaced the C code with its C++ equivalent. This made the code smaller, more familiar, and more readable.
Tested at every stage, the reproduced scenario completed in under 20 minutes instead of a couple of hours. But, if something sounds too good to be true, it’s often too good to be true. Did I shatter our gem without realizing it? I did my own investigation and consulted colleagues before finally concluding that everything still worked as it should. Still in disbelief, we began dissecting the changes to understand exactly what happened.
We compared performance profiles before and after the update, which identified the specific code that was now much faster, revealing that the main contributor was the introduction of a standard vector. In technical terms, we used C-style arrays as our vector type in the old code, and these were reallocated for every single pushback. In the new code, however, the pushback of an element is amortized constant, saving a lot of CPU time.
Convinced we did the right thing, we took one last look at the code. Because we now understood it better, we could make minor additional changes to further reduce computing time to an acceptable two minutes.
So, we improved performance by 99% just by polishing our code, using modern C++. It’s now easier to understand and maintain, and this all resulted from the great work of the people who developed it when I was still in primary school.
Time will tell if the code we write today ends up being just as elegant. I hope one day that I may be an onlooker as one of my successors, not yet alive, looks over my 2021 state-of-the-art code and recognizes beauty in what we write today, even as it becomes outmoded. Old code isn’t garbage, it’s history. And with the right care, old gems can keep their sparkle and still deliver value to our customers.
Joining OMP in 2012, Jeroen has delivered value in a number of areas of responsibility. His current focus as a C++ expert is delivering qualitative functionalities in the forecasting solution and supporting a range of developer projects.