Speed Freak

Your Legacy

CoolBeans: From College to Industry — Tue, 13 Feb 2007 10:47:36 GMT

I'm sure you want to have a legacy. People will remember you and tell stories about what you did and

re: Speed Freak

Kurt Mosiejczuk — Tue, 09 Jan 2007 18:33:18 GMT

This makes me think of the surprise about the linux kernel within the past year or two. Someone compiled it with the "-Os" (optimizing for size, not speed) and found the kernel ran *faster*. Why? Because it fit better into caches.

re: Speed Freak

TAG — Tue, 09 Jan 2007 17:01:28 GMT

> is less an influence in languages such as Java or C#

This is false. In Java/C# new instead of using same CPU optimizations over and over - people start coding crazy algorithms for speed.

In contrast to CPU optimizations - sometimes those new algorithms are incorrect.

> Write Macros!

Macros are simply wrong ! They will evaluate (x) value twice. This reason alone is more then sufficient.

re: Speed Freak

mikefried — Tue, 09 Jan 2007 02:40:29 GMT

Here are some similar thoughts along these lines:

Premature optimization is the root of all evil. Yet another reason not to write macros is that you lose type safety. This is not a reason to write templates instead of macros; although templates are type safe, they don't scale well to being used like macros and end up generating a lot of code when used poorly. That being said, when used *well*, they can be used to generate more readable and useful code. C# generics (templates) are designed a bit better (harder to use templates in C# like macros in C++) and C# generics are reasonably well designed with Visual Studio in mind.

Although premature optimization is the root of all evil, you shouldn't be afraid to use the right data structures to make your implementation scale well. For example, if you need to have offsets into an array to turn an O(n) operation into an O(m) operation where m << n then you will probably win big if you do this operation often. It is important to design the code you write first so that it accomplishes the task in a reasonably well designed way and also so that it runs acceptably fast. Acceptably fast can mean sub-optimal, but it normally means not slow enough that the user notices. That is a reasonable heuristic.

Optimization costs you and everyone maintaining your code, so you should make sure that it is done where it matters most. Of course, you can and should take pride and optimize your algorithms to the point where the user shouldn't notice even on mildly slow hardware and when using somewhat large datasets, but the point is that you only have a limited amount of time on this earth, and the time you spend on unnecessary optimization is time you can't spend doing more useful things.