What is the most ridiculous pessimization you've seen?

 

We all know that premature optimization is the root of all evil because it leads to unreadable/unmaintainable code. Even worse is pessimization, when someone implements an "optimization" because they think it will be faster, but it ends up being slower, as well as being buggy, unmaintainable, etc. What is the most ridiculous example of this that you've seen?

On an old project we inherited some (otherwise excellent) embedded systems programmers who had massive Z-8000 experience.

Our new environment was 32-bit Sparc Solaris.

One of the guys went and changed all ints to shorts to speed up our code, since grabbing 16 bits from RAM was quicker than grabbing 32 bits.

I had to write a demo program to show that grabbing 32-bit values on a 32-bit system was faster than grabbing 16-bit values, and explain that to grab a 16-bit value the CPU had to make a 32-bit wide memory access and then mask out or shift the bits not needed for the 16-bit value.

I think the phrase "premature optimization is the root of all evil" is way, way over used. For many projects, it has become an excuse not to take performance into account until late in a project.

This phrase is often a crutch for people to avoid work. I see this phrase used when people should really say "Gee, we really didn't think of that up front and don't have time to deal with it now".

I've seen many more "ridiculous" examples of dumb performance problems than examples of problems introduced due to "pessimization"

  • Reading the same registry key thousands (or 10's of thousands) of times during program launch.
  • Loading the same DLL hundreds or thousands of times
  • Wasting mega bytes of memory by keeping full paths to files needlessly
  • Not organizing data structures so they take up way more memory than they need
  • Sizing all strings that store file names or paths to MAX_PATH
  • Gratuitous polling for thing that have events, callbacks or other notification mechanisms

    • What I think is a better statement is this: "optimization without measuring and understanding isn't optimization at all - its just random change".

    Good Performance work is time consuming - often more so that the development of the feature or component itself.

    Databases are pessimization playland.

    Favorites include:

  • Split a table into multiples (by date range, alphabetic range, etc.) because it's "too big".
  • Create an archive table for retired records, but continue to UNION it with the production table.
  • Duplicate entire databases by (division/customer/product/etc.)
  • Resist adding columns to an index because it makes it too big.
  • Create lots of summary tables because recalculating from raw data is too slow.
  • Create columns with subfields to save space.
  • Denormalize into fields-as-an-array.

    • That's off the top of my head.

    链接地址: http://www.djcxy.com/p/86744.html

    上一篇: 内联汇编语言比本机C ++代码慢吗？

    下一篇: 什么是你见过的最荒谬的悲观化？