> It's true that over-complication is the bane of good performance, but lets not pretend it is, or ever was, easy to get great performance.
It's easier to overcomplicate things, than it is to keep things simple. Especially when there are changes to specification(which means always :)). And often performance comes as a bonus, when we simplify things. So I think GP had it right.
Recently I've noticed in my code (ok, friend pointed it out to me), that I often leave too general code mixed with code with specific assumptions. Like - at first I've assumed nothing, so code was general, but more complicated than neccesary. Then I've learnt a few things, made more assumptions to get what I need faster, but I've left the general parts of code in place (maybe I'll need them later, besides more general == better, right?), even thought I could replace them with simpler and shorter and faster code, if I rethought these parts with new asumptions.
So code is more complicated than it's needed, and won't work in general case anyway, and depending where somebody starts reading the code, he will think differently about what he can assume about data.
Friend had replaced 2 instances of NumberAssigner class, synchronised between threads, with two instances of private int variables, and removed NumberAssigner class altogether :)
It's easier to overcomplicate things, than it is to keep things simple. Especially when there are changes to specification(which means always :)). And often performance comes as a bonus, when we simplify things. So I think GP had it right.
Recently I've noticed in my code (ok, friend pointed it out to me), that I often leave too general code mixed with code with specific assumptions. Like - at first I've assumed nothing, so code was general, but more complicated than neccesary. Then I've learnt a few things, made more assumptions to get what I need faster, but I've left the general parts of code in place (maybe I'll need them later, besides more general == better, right?), even thought I could replace them with simpler and shorter and faster code, if I rethought these parts with new asumptions.
So code is more complicated than it's needed, and won't work in general case anyway, and depending where somebody starts reading the code, he will think differently about what he can assume about data.
Friend had replaced 2 instances of NumberAssigner class, synchronised between threads, with two instances of private int variables, and removed NumberAssigner class altogether :)