A Performance Story from an Old Job

I used to work at a place called Rogue Wave Software.

It was my first real job and a fantastic place to cut my teeth. Even though it was the '90's, the developers there had a better concept of what software design was than a lot of the developers I've met, since.

One little story that still amuses me to this day involves one of their products, DBTools.h++ (later SourcePro DB). DBTools.h++ had a very object-oriented design. Even today, that would be true but it was especially true at the time.

This anecdote is about how that design held up to other approaches with regards to performance.

I Can't Believe Some People Still Need Virtual Method Calls Defended

In the 1990's, a lot of people labored until the belief that indirect (virtual) method calls were expensive. After all, you have to read a value out of memory and then use that as the address of a call! How could it ever compete with the one-clock-tick-long conditional jump?

I hear this less today but I still hear it every once in a while and I'm shocked when I do because it was nonsense, even in the late nineties.

In terms of performance, it didn't matter, then, and it doesn't matter, now. I'm only addressing it because a belief that discourages the usage of virtual methods is a dangerous one which must be disabused.

Object-Oriented Performance

Long ago, in a land now distant to me, I worked for a very successful company.

They were the kind of company that wasn't successful because they were good at software development. They were good at something else and they had to do some software development to make that offering in the modern era.

I was brought into one team by a friend of mine in order to change their thinking. Years later, I heard they still reference me as the reason why they write tests first.