Early in my programming career I was in love with pointer twiddling, lean code,

Question

Early in my programming career I was in love with pointer twiddling, lean code, doing everything with as little layers of abstraction as possible and so on. The code was very C like I would say, close to metal and clever.

Time has passed, I have a lot more experience, and I'm noticing my attitude towards the code has changed.

And with changed, I mean, I don't want to bother about everyday stuff anymore, unless it's super easy to do.

If there is a string concatenation, I will never choose raw pointers deliberately. If I need to concatenate stuff, I might add a quick guess reserve for an STL container, but I don't want to bother with preallocated buffers, C like APIs, caches, avoiding hitting the disk, or trashing. I know realloc might happen from time to time, including all the heap locks, extra copying and so on, but I don't even bother anymore.

Maybe, it is because I have spent some time early in my career where I thought of a clean and beautiful schemes with worker threads that process large amount of trivial data, only to find out later that the whole unoptimized realloc+copy+realloc+copy+realloc+copy+5 layers of wrappers doesn't even register in profiler.

Maybe it's because I've seen how compilers sometimes do magic.

However, such trivial things do add up. When all your code base uses higher order constructs, it has chances that there will be some realloc all over the place, or cold disk hits, that can cause a general perception of a slow application.

Sort of like WTL vs MFC. Or how you instantly know that the application is written in Java when you launch it.

But is it really? Is there any comparisons of software that's using only very lean and smart code vs software that uses generic containers all over the place?

Would you even feel a difference if the string allocation throughout the program would be using prereserves and smart moves vs lazily calling string.append in every place where there is a need for such functionality?

Do you try to implement mitigation solutions for such simple, well known things that are cheap to execute anyway?

Can software turn into bloatware just because extra caution is not applied to every line of code?

Explanation / Answer

No. Profilers can quickly and adequately tell you exactly where the problem spots are.

The reason why some frameworks are problematic is because when the problem spot is in a framework or virtual machine function, you are screwed. If you have, realistically, complete performance control over the application then go nuts. This is why you can tell when an app is launched with Java- when the slowdown is in the JVM code, there's nothing any dev can do about it. However, this tends not to be an issue with C++ development in general.

Not to mention that the power of compilers to cut the crap and make your very high-level code go much faster grows every year.

Is there any comparisons of software that's using only very lean and smart code vs software that uses generic containers all over the place?

Hate to break it to you, buddy, but generic containers are lean and smart. One of their primary advantages is that because you don't have to re-write them for every type that ever lived, you can afford to write high-performance code once and re-use it. It's a simple application of DRY that improves both performance and reliability. Writing it yourself 999999 times isn't the smart code, that's the dumb code.

Related Questions

Navigate

• Browse (All)
• Browse E
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.