It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
ZFR: VBA macros (yes, I worked a lot with those :( ) Often repairing others' "code".

The Microsoft employee who thought it would be a good idea to include "Record macro" with Excel, should be forced to work fixing the code people create using this function.

Example of one of the worst offenders:

To sort a column:
_Select the column
_Copy
_Create new sheet
_Paste
_Sort (using Excel's built in sort)
_Select the sorted column
_Copy
_Select original column
_Paste
Are those the awful macros that many antivirus programs lept to block in the 90s because arbitrary code could be executed through them?
Can't quote it here since I deleted it. But when debugging a program that my predecessor at the institute I was working at wrote, I found it contained a block of about 2000 lines (C++) that did exactly nothing but wasting processing power. I could never figure out what this sub-routine was supposed to do. It was called quite often in the code and made lots of calculations that were then never used. So I deleted it and all references to it and voila, the program was much more stable and a lot faster too.
avatar
Lifthrasil: Can't quote it here since I deleted it. But when debugging a program that my predecessor at the institute I was working at wrote, I found it contained a block of about 2000 lines (C++) that did exactly nothing but wasting processing power. I could never figure out what this sub-routine was supposed to do. It was called quite often in the code and made lots of calculations that were then never used. So I deleted it and all references to it and voila, the program was much more stable and a lot faster too.
Neither AMD, nor Intel will ever hire you. But your predecessor. =)
avatar
Wishbone: Then of course there's code that's not bad as such, in fact it's so good it's almost magical, but quite unintuitive and extremely difficult to understand. Example: The fast inverse square root algorithm.
Good general explanation..

Error range of 0.17%, subtraction and multiplications used, but not divides (which is the slowest). It feels like the main advantage this would have is if you were doing software rendering and a lot of people still didn't have FPU's... Quake1 would hit that requirement, but not sure about Quake 2 and on...

Although for the code shown i'd have probably used a union instead of pointers to override type, although optimization might make that moot...
avatar
Lifthrasil: Can't quote it here since I deleted it. But when debugging a program that my predecessor at the institute I was working at wrote, I found it contained a block of about 2000 lines (C++) that did exactly nothing but wasting processing power. I could never figure out what this sub-routine was supposed to do. It was called quite often in the code and made lots of calculations that were then never used. So I deleted it and all references to it and voila, the program was much more stable and a lot faster too.
That's probably the problem. Noone could figure out what it was supposed to do, so noone ever dared delete it before, in case it was something important. That's actually quite common, and is a frequent cause of "bloat-over-time".
avatar
Wishbone: Then of course there's code that's not bad as such, in fact it's so good it's almost magical, but quite unintuitive and extremely difficult to understand. Example: The fast inverse square root algorithm.
avatar
rtcvb32: Good general explanation..

Error range of 0.17%, subtraction and multiplications used, but not divides (which is the slowest). It feels like the main advantage this would have is if you were doing software rendering and a lot of people still didn't have FPU's... Quake1 would hit that requirement, but not sure about Quake 2 and on...

Although for the code shown i'd have probably used a union instead of pointers to override type, although optimization might make that moot...
Actually, according to
http://blog.regehr.org/archives/959

the fastest way would be something like this (f float):
{
int i;
memcpy(&i, &f, 4);
}

(The memcpy() call is optimized into the lease assembly code.)

When it comes to optimization, sometimes compilers can surprise you, so be careful. (Of course, there are other surprises to watch out for, like CPUs and other hardware having unexpected performance characteristics.)
avatar
dtgreene: Actually, according to
http://blog.regehr.org/archives/959

the fastest way would be something like this (f float):
{
int i;
memcpy(&i, &f, 4);
}

(The memcpy() call is optimized into the lease assembly code.)

When it comes to optimization, sometimes compilers can surprise you, so be careful. (Of course, there are other surprises to watch out for, like CPUs and other hardware having unexpected performance characteristics.)
Hmm seems like a roundabout way of just saying i=f, for a 32bit move...

Although glancing at the code output shown i have to wonder why all those codes are added. Depends, perhaps it generates different code for signed and unsigned code. But it's not a surprise during optimization it will weigh the time vs code size vs data to be copied and determine if inlining is worth it.