Programming Optimization

[scratt]

I found this article very interesting... Particularly some of the optimizations, and the reasons given for them, discussed at the bottom...

The whole page is about the elusive subject of program performance optimization, but it get's interesting from the #misconceptions part...

http://www.azillionmonkeys.com/qed/optimize.html#misconceptions

[Kickaha]

Kewl. Yeah, the misconceptions for never optimizing are nearly as annoying as the ones for not using OO. :P Proper tool in the proper place, I always say.

Good page, thanks for sharing it. :)

[trainee]

That's an interesting article.
Thinking about how many cycles are wasted for one call to a Java Enterprise-Bean makes me sick!

[Enki]

That's an interesting article.
Thinking about how many cycles are wasted for one call to a Java Enterprise-Bean makes me sick!

So write the entire bean functionality from scratch with low level components. Whining about the prices paid in performance for choosing pre-provided functionality in a VERY high level language is wasted breath. You pay a price no matter what you program. You choose ease of development and trade off max performance, or you choose max performance and buy lot's of development. The fabled middle ground pretty much doesn't exist unless you are developing apps with spartan functionality.

[Kickaha]

Strongly agree.

Look at the total time spent during a product's lifecycle, including development, maintenance, and runtime, and the first two *greatly* swamp that last one, unless you use high-level abstractions appropriately.

There will be times where performance is paramount, but for those *specific* cases, you optimize where necessary, and nowhere else. I've done systems that ranged internally from high-level OO libraries down to assembly. I tend to start at the most abstract, and work my way down. That optimizes the development time first, and runtime second. Any other way of doing it is guaranteed to result in a product that never gets finished.