tags:

views:

712

answers:

4

Raymond Chen has this to say on his recent post on code optimizations... Obvious optimizations - one that begs to be optimized - tend to be "de-optimizations" if you consider all that need to be considered...

I'm sure you must have come across / even coded optimizations you were embarrassed about after you learnt more...

Care to share?

+2  A: 

See also this question.

Federico Ramponi
Actually, I saw that question quite a while ago and have only just realized that pessemization was a play on optimization. Now I'm putting my rampant inability to understand humor out for the entire SO community to laugh at :-).
paxdiablo
+5  A: 

My favorite example would be the XOR swap algorithm:

// swap these two values:
int x = 4;
int y = 2;
// original:
int temp = x;
x = y;
y = temp;
// optimized version:
x ^= y;
y ^= x;
x ^= y;

Yes, it uses no temporary variable, and can usually be done in three processor cycles, but it sure isn't obvious what it does!

e.James
And not only that. It only works on integers.
Luke
This is a particular annoyance to me - people making their code less readable because, OMG, they don't want to add an extra 4 bytes to the stack. What, are these people running on Intel 4004 or RCA 1802 CPUs?
paxdiablo
I think some compilers nowadays can detect and optimize the first case.
strager
@strager: and so they should!
e.James
Doesn't this cause an overflow with some values, too?
Matthew Schinckel
This "optimization" adds data dependencies where the original can be dealt with by the hardware via register renaming. In fact, the original can quite possibly take *zero* cycles.
CesarB
@Luke: it works with any value. Of course XOR has to treat the values as integers.
Bastien Léonard
This is now an unoptimization. Causes CPU stalls, and is often slower than the normal solution.
GMan
Why would it cause CPU stalls? I'm not disagreeing with you, I'm genuinely curious about the failure mechanism. At any rate, I would definitely rank this one in the "not so hilarious" category.
e.James
Because line 2 cannot execute until line 1 is done, and line 3 cannot execute until line 2 is done. So the CPU will be blasting long then stop and go "1, 2, 3" then keep going. Contrarily, `x = y` and `y = temp` can execute at the same time.
GMan
That makes sense. Thanks!
e.James
+8  A: 

Duff's Device, which is so twisted that it looks like it shouldn't even compile in ISO C:

int n = (count + 7) / 8;
switch (count % 8) {
case 0: do { *to = *from++;
case 7:      *to = *from++;
case 6:      *to = *from++;
case 5:      *to = *from++;
case 4:      *to = *from++;
case 3:      *to = *from++;
case 2:      *to = *from++;
case 1:      *to = *from++;
           } while (--n > 0);
}
Matt Campbell
Ah, the joy of half-unrolling loops. =]
strager
This device is an abomination and has no place in today's world of high-speed large-address-space computers. Sure, it's cool, in a nerdy sort of way, but incredibly unnecessary.
paxdiablo
... hence its inclusion in a list of abominable code optimisations. I'm not exactly advocating it's use by posting it in this thread!!!
Matt Campbell
+1, and added a pointer in my "spaghetti code" question. I had never seen this pearl before
Federico Ramponi
+5  A: 

My favourite is

// original code
int a[10];
a[5] = 3;

// optimized code
int a[10];
*(a + 5) = 3;

Yes, all of a sudden, that's magically faster!!</sarcasm>

Johannes Schaub - litb
Actually, it should be "int a[10]; a += 5; *(a+N) = 3;" since, on average, it's faster for the CPU to reach a given element from the middle of the array. If you wanted a[9], it would have to count all the way up from 0 with the original solution. In my optimization, it has to count 5 at most :-)
paxdiablo
Oh yes, Pointer Math. Yet another reason I'm glad I switched to managed languages.
Matt Campbell
@pax, `a+=5` won't work because the pointer to an array can't be changed.
Blindy