18

There is a comment on the question Can the use of C++11's auto improve performance? that scored many votes and suggests “makes it less likely to unintentionally pessimize” as an answer. I've never noticed this term before. I guess it is somehow the opposite of optimization.

Can anyone give a more detailed definition? What does it mean in the context of programming? How would pessimized code look like?

Community
  • 1
  • 1
DaBrain
  • 3,065
  • 4
  • 21
  • 28
  • Out of a guess I suppose it isn't a technical term.. – Marco A. Sep 16 '15 at 21:17
  • I suppose you could contrive some example where, before `auto`, you might make an improper assumption about a return type, resulting in an overly expensive and altogether needless type conversion. That would be a pessimization. – AndyG Sep 16 '15 at 21:19
  • Related post: http://stackoverflow.com/questions/15875252/premature-optimization-and-premature-pessimization-related-to-c-coding-standar – R Sahu Sep 16 '15 at 21:20
  • 2
    Opposite of "optimize* - make the code less performant. – Galik Sep 16 '15 at 21:46
  • 1
    wow, a question not directly related to code, and no white night has came to explain the rules of the site and try shut it down. incredible. – Puddle Dec 21 '18 at 15:15

3 Answers3

19

It's mostly a play on words, a pessimist is the opposite of an optimist. And pessimisation is writing less than optimal code.

Both compilers and the programmer can pessimise code by having bad constructs that for example copy things when it isn't required. The auto keyword will at the very least ensure that you get the "closest type", so there is no (unnecessary) type conversion.

Note that pessimisation is when there is no BENEFIT to the code being "not optimal":

It is not pessimisation "if we spent six months optimising this, it would run 0.5% faster". Unless it's a requirement to be 0.5% faster, spending six months on it is probably a waste of time.

Also, required functionality, such as security, is not pessimisation: "The code is slower than it possibly could be because we made it secure".

A debug build is mot "pessimal" because it has asserts to catch NULL pointer dereferences and checking the index of array accesses, etc. As long as those asserts and checks are written such that they "disappear" when you enable the release mode. [and if your code is running a nuclear power-plant, you probably don't want crashes EVER, see "security" above]

An old example I've seen is this C-string loop:

char str [large_number] = "... several kilobytes of text (read from file) ... ";

for(char *p = str; p < str+strlen(str); p++)
{
   ... do stuff with p ... 
}

If do stuff with p is sufficiently complex, the compiler won't realize that strlen is a constant value, and will perform strlen every iteration of the loop. The loop will run MUCH faster if we did:

for(char *p = str, *e = str+strlen(str); p < e; p++)
{
   ... do stuff with p ... 
}

[Not an example of auto, I'm afraid]

Leon
  • 31,443
  • 4
  • 72
  • 97
Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • 3
    Most code is less than optimal by some standard. I think the crucial point is that it is less optimal than it could be, with no gain. – juanchopanza Sep 16 '15 at 21:23
  • @juanchopanza Neither word is considered to be an absolute. Optimized code isn't usually perfectly optimal, it's just supposed to be more efficient than non-optimized. – Barmar Sep 16 '15 at 21:33
  • 1
    @juanchopanza: Added more verbiage (pessimising the brevity of the post) and explaining in more detail the distinction [at least that's the intended effect] – Mats Petersson Sep 16 '15 at 21:36
  • 1
    @Barmar Agreed. I didn't mean to imply there is a hard definition for "optimal". The general idea is that you make something that can only make things worse, for reasonable definitions of worse (less efficient, harder to read, harder to test, even longer to type...) – juanchopanza Sep 16 '15 at 21:41
  • When you say "less than optimal code" are you using that as a euphemism? Like when someone asks you to taste their new food recipe, and it tastes like fermenting moist debris at the bottom of a diaper pail, you might say it tastes less than optimal? Like "your code is hard to read, and takes more than a hundred times longer than it could; so, it's less than optimal." – timeSmith Feb 04 '23 at 13:48
11

Pessimizing implies a little more than just giving performance that isn't the best it could be.

In general, it's doing something, typically in the interest of improving performance, that actually hurts performance instead. Although not absolutely required, there's frequently the implication that the result is actually worse than if you'd just done something simple and obvious.

In this case, using auto to specify the type of the variable is simple and obvious--and regardless of whether it's precisely optimum, it establishes a baseline level of performance. When/if you specify the type explicitly, you basically just end up with two choices: explicitly define the same type auto would have deduced (getting exactly the same performance), or specifying some other type (in which case there are really only two possibilities: it won't work at all, or it'll do some sort of conversion that almost inevitably hurts performance).

Summary: pessimization isn't usually just "getting less that optimal performance". It's usually "doing extra work (possibly in the hope of improving performance) that actually hurts performance."

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
5

You could have just looked it up in a dictionary, such as this page, which says:

pessimize (verb):

(transitive) To make (something) less efficient, such as a computer program.

Roman Kotenko
  • 489
  • 7
  • 16