Any surveys about the premature optimization status nowadays?

[jimxoch]

Hello list,

Having read many discussions about software optimization, I have
noticed that in most of them the premature optimization is regarded as
a very frequent habit of the professional software developers.
However, working as a professional programmer myself, I know for a
fact that the reality can differ a lot from these assumptions.
Furthermore, while I understand that premature optimization was
probably a frequent habit back in the 60s and 70s, when programming
was more like an art and less like a 9 to 5 job, I seriously doubt
that the situation remains the same till today.

In all the jobs I had till now, neither me nor my colleagues have ever
had the luxury of doing premature optimization frequently. Deadlines
are usually too tight, and often we barely have the time to complete
the features and debug our projects, working overtimes in many
occasions. Of course, back in my student days, when I was programming
mostly for fun, I can remember myself having the habit of optimizing
prematurely, but this habit quickly disappeared when I started to work
as a professional. Spending large amounts of time in premature and
unnecessary optimizations is very unrealistic for most (if not all)
the professional developers I have met till now! On the contrary,
while working under stress, it often happens to underestimate and
overly-delay some optimizations, hoping that we will probably avoid
them and save some valuable time, only to realize that sometimes in
order to have efficiency you have to design for it.

Noticing such a huge difference between the discussions I have read in
the internet and the reality I experience in my professional life, I
wonder if there exist any scientific surveys (or even indicative
polls) which can provide objective and complete information regarding
the way the programmers use to optimize nowadays. I will be extremely
grateful to anyone who can inform me about the existence of such
surveys.

Thank you very much,
Jim Xochellis

Homepage: http://jimxoch.freehost.gr/

 

[Juha Nieminen]

Having read many discussions about software optimization, I have
noticed that in most of them the premature optimization is regarded as
a very frequent habit of the professional software developers.
However, working as a professional programmer myself, I know for a
fact that the reality can differ a lot from these assumptions.
Furthermore, while I understand that premature optimization was
probably a frequent habit back in the 60s and 70s, when programming
was more like an art and less like a 9 to 5 job, I seriously doubt
that the situation remains the same till today.

I think it depends on the exact definition of "premature
optimization". There are two possible definitions:

1) Micro-optimization (also called "hacker optimization"), often done
in places which don't need it and don't benefit from it at all, at the
cost of clarity and maintainability, for the sole reason that the
programmer has completely wrong priorities. Micro-optimization is seldom
motivated by actually profiling existing code and finding the need for
it (which is what makes it premature optimization).

2) The opposite of "premature pessimization". In other words, rather
than thinking "I will use a naive solution for this critical part of the
code and optimize it later", the programmer thinks of the optimal
solution first and only then implements that critical part. Unlike
micro-optimization, this kind of optimization happens at the algorithm
level, rather than at the hardware level.

IMO option 1 is a bad thing, and *not* doing option 2 is also a bad
thing. Option 2 *might* in some cases delay the implementation of the
software by some amount without any real benefit (ie. even though the
algorithm is efficient and sound, it never actually gets run on an
amount of data which would show a benefit). This would be what makes it
"premature optimization". However, IMO it's in no way a bad thing
because the code will be already prepared for the case that in the
future the domain of the application expands, so that it will be able to
handle expanded data sets efficiently without having to go over the
existing code to optimize naive algorithms.

 

[Rune Allnor]

  2) The opposite of "premature pessimization".

What term is used for this? Pragmatic preparation?

  However, IMO it's in no way a bad thing
because the code will be already prepared for the case that in the
future the domain of the application expands, so that it will be able to
handle expanded data sets efficiently without having to go over the
existing code to optimize naive algorithms.

Agreed.

Rune

 

[jimxoch]

Thank you very much for answering and thank you for your very
interesting thoughts.

However my question is not "what is the correct way to perform
optimizations". (Which is quite subjective by the way...) The question
is: How *actually* the professional programmers of our generation
perform the optimizations in the real world? What is more frequent, do
they optimize too late or too early? Do you happen to know any surveys
or polls which could enlighten us a little?

Best regards,
Jim Xochellis

Homepage: http://jimxoch.freehost.gr/

 

[apatrinos]

It seems to me that the golden rule is "write correct code first,
optimize it later". However this does not rule out applying well known
optimizations, algorithms or optimal library routines in the first
writeup of the code. For example, when calculating the value a high
degree polynomial, Horner's rule is an accuracy optimization that
could be applied in the first place, although this is rarely done
because it takes maybe ten minutes to write instead of one.

Obiously when time is a strict constraint something's gotta give.
Mostly this is quality, in any form, e.g. bugs or speed of execution
and one's manager has to be aware of this and not place absurd
demands. With regard to surveys, I think they are no replacement for
lessons learned from years of experience. Moreover, there is no
guarantee that just because most people use one approach, this is the
right one, or that it is the best one for the particular circumstances
one faces.

-Anthony Patrinos

 

[Krice]

How *actually* the professional programmers of our generation
perform the optimizations in the real world? What is more frequent, do
they optimize too late or too early?

Don't try to think that there is a simple answer to that.
Optimizations are still required in software like games, but
I think premature optimization is not common in professional
development.

 

[Rune Allnor]

How *actually* the professional programmers of our generation
perform the optimizations in the real world? What is more frequent, do
they optimize too late or too early?

I think if you asked, most people would probably say that
everybody else optimized to early or too late; they themselves
optimized just enough at just the right places.

The truth, however, is probably that results depend on the
environment where they are created.

I am not a professional programmer, but work in an enevironmet
where time is scarce and pressure to deliver results is high.
Much like - according to some people's claims - the programming
business.

My impression is that people in this kind of environment just
don't think. There is little planning or prioritazion of tasks.
Instead, people tend to react to stimulus: Whoever shoutest
loudest that "quit what you're doing and get *this* done ASAP!!"
will get their tasks moved to the top of the to-do list. Not
necessarily done, but moved to the top.

This is not at all a good environment for creating Great reults
in my day job, and I doubt if it is in programming.

Rune

 

[Pascal J. Bourguignon]

Having read many discussions about software optimization, I have
noticed that in most of them the premature optimization is regarded as
a very frequent habit of the professional software developers.
However, working as a professional programmer myself, I know for a
fact that the reality can differ a lot from these assumptions.
Furthermore, while I understand that premature optimization was
probably a frequent habit back in the 60s and 70s, when programming
was more like an art and less like a 9 to 5 job, I seriously doubt
that the situation remains the same till today.

In all the jobs I had till now, neither me nor my colleagues have ever
had the luxury of doing premature optimization frequently. Deadlines
are usually too tight, and often we barely have the time to complete
the features and debug our projects, working overtimes in many
occasions. Of course, back in my student days, when I was programming
mostly for fun, I can remember myself having the habit of optimizing
prematurely, but this habit quickly disappeared when I started to work
as a professional. Spending large amounts of time in premature and
unnecessary optimizations is very unrealistic for most (if not all)
the professional developers I have met till now! On the contrary,
while working under stress, it often happens to underestimate and
overly-delay some optimizations, hoping that we will probably avoid
them and save some valuable time, only to realize that sometimes in
order to have efficiency you have to design for it.

Noticing such a huge difference between the discussions I have read in
the internet and the reality I experience in my professional life, I
wonder if there exist any scientific surveys (or even indicative
polls) which can provide objective and complete information regarding
the way the programmers use to optimize nowadays. I will be extremely
grateful to anyone who can inform me about the existence of such
surveys.

It is significative that you post that on C++.

Using C++ to develop most projects is in itself a premature
optimization and the main source of deadline overshooting.


If programmers wheren't thinking all the time about the processor
cycles and whether they should be using a std::vector or a std::list,
they wouldn't be optimizing unrelevant stuff, but would be thinking
about the user's problem and its solution within that domain, not that
of pointers vs. smartptr, references vs. copy, RIAA vs. exceptions,
etc. All these things are found only in programming languages, not in
domain problems.

 

[Francesco S. Carta]

It is significative that you post that on C++.

Using C++ to develop most projects is in itself a premature
optimization and the main source of deadline overshooting.

Pascal, can I ask you why you don't lose a chance to post things like
that?

It is significant that you post messages like that on c.l.c++, do you
enjoy language advocates flaming each other, eventually being one of
the contestants?

And apart of that, how can you call the choice of a language as being
a "premature optimization"?

Translating a complete, non-trivial program from a language to another
isn't exactly child-play and if a program has the chance of _needing_
to be implemented in a language, choosing another in first place is
not a "premature pessimization", it is a "serious project management
flaw", in my opinion.

But I'm an hobbyist and all of this stuff should be outside of my
worries.

@OP: Sorry Jim, I have no idea about the existence of surveys and
alike, wrt your original topic.

Have good time,
Francesco

 

[Pascal J. Bourguignon]

Pascal, can I ask you why you don't lose a chance to post things like
that?

It is significant that you post messages like that on c.l.c++, do you
enjoy language advocates flaming each other, eventually being one of
the contestants?

And apart of that, how can you call the choice of a language as being
a "premature optimization"?

Translating a complete, non-trivial program from a language to another
isn't exactly child-play and if a program has the chance of _needing_
to be implemented in a language, choosing another in first place is
not a "premature pessimization", it is a "serious project management
flaw", in my opinion.

You don't have to translate the whole program.

Write your program in the highest level programming language you may
find.

If you determine that in fact it is too slow, and that it is not
because of a bad choice of algorithms, but because of fundamental
constraints due to the language, you can isolate the parts that are
too slow, and rewrite them in a low level language such as C or C++.

But only those parts.

 

[Francesco S. Carta]

You don't have to translate the whole program.

Write your program in the highest level programming language you may
find.

If you determine that in fact it is too slow, and that it is not
because of a bad choice of algorithms, but because of fundamental
constraints due to the language, you can isolate the parts that are
too slow, and rewrite them in a low level language such as C or C++.

But only those parts.

OK, I fully understand your position.

The thing that amazes me is the fact that you consider C++ as just a
low level programming language.

C++ is _also_ a low level programming language - the kind of languages
that have been called "close to the metal" somewhere else.

But it is also a high level language. And a pretty good one, in my
small experience.

I think that a stronger emphasis should be put on the experience of
the programmers available on a team.

If they're "proficient and well mannered" in C++, there is no need to
"force" them to use another language only because that language would
give them less potential freedom, "forcing" them (eventually, but not
necessarily) to "good manners".

On the other hand, if the available programmers happen to misuse C++
and can be equally productive and eventually less error prone using
another language, by all means they should either learn to use C++ in
a better way or choose to use that other language.

In other words, blame the experience level of the actual people that
write the code, don't blame the language itself.

Have good time,
Francesco

 

[ld]

You don't have to translate the whole program.

Write your program in the highest level programming language you may
find.

If you determine that in fact it is too slow, and that it is not
because of a bad choice of algorithms, but because of fundamental
constraints due to the language, you can isolate the parts that are
too slow, and rewrite them in a low level language such as C or C++.

But only those parts.

The problem is what you call a "high level programming language"
depend on the task to perform. Examples coming to my mind are:

C++ could be the _only_ "high level programming language" suitable
when the goal is to provide a library which allow to combine units of
code (classes) and generate optimized algorithms (aka generative
programming + specialization) as described in (p 429-431):

http://www-ia.tu-ilmenau.de/~czarn/gmcl/a4/matrix.gz

C could be the _only_ "high level programming language" suitable when
the goal is to implement a powerful object model on top of an
efficient language. An example is the C Object System which allows to
build non-intrusive efficient components like the proxy Locker to
remove deadlock in threaded programs or libraries.

So if by "high level programming language" you mean languages
dynamically typed, interpreted, or having a powerful macro system, you
are focusing on specific aspects which fits your needs.

cheers,

laurent.

 

[ld]

Hello list,

Having read many discussions about software optimization, I have
noticed that in most of them the premature optimization is regarded as
a very frequent habit of the professional software developers.
However, working as a professional programmer myself, I know for a
fact that the reality can differ a lot from these assumptions.
Furthermore, while I understand that premature optimization was
probably a frequent habit back in the 60s and 70s, when programming
was more like an art and less like a 9 to 5 job, I seriously doubt
that the situation remains the same till today.

In all the jobs I had till now, neither me nor my colleagues have ever
had the luxury of doing premature optimization frequently. Deadlines
are usually too tight, and often we barely have the time to complete
the features and debug our projects, working overtimes in many
occasions. Of course, back in my student days, when I was programming
mostly for fun, I can remember myself having the habit of optimizing
prematurely, but this habit quickly disappeared when I started to work
as a professional. Spending large amounts of time in premature and
unnecessary optimizations is very unrealistic for most (if not all)
the professional developers I have met till now! On the contrary,
while working under stress, it often happens to underestimate and
overly-delay some optimizations, hoping that we will probably avoid
them and save some valuable time, only to realize that sometimes in
order to have efficiency you have to design for it.

Noticing such a huge difference between the discussions I have read in
the internet and the reality I experience in my professional life, I
wonder if there exist any scientific surveys (or even indicative
polls) which can provide objective and complete information regarding
the way the programmers use to optimize nowadays. I will be extremely
grateful to anyone who can inform me about the existence of such
surveys.

Thank you very much,
Jim Xochellis

The answer varies widely if the software developers are writing
applications, libraries or operating system layers. The two lasts are
much more demanding since interfaces cannot be changed easily once
"published". Anticipating all cases of use is difficult which means
that components must be optimized somehow to fulfill the full range of
"possible" use. This could lead to a significant amount of extra work
comparing to the development of applications where the domain of use
is better known and controlled.

cheers,

ld.

 

[Gert-Jan de Vos]

Write your program in the highest level programming language you may
find.

More general: write your program using the most appropriate tools for
the job. There is no single objective most appropriate tool, this
depends highly on context. This context includes:

- existing code base
- team experience with these tools
- available libraries
- external interfaces
- business goals

Most of these have little to nothing to do with inherent programming
language syntax or efficiency, yet I think they have a stronger
influence on the actual language of choice.

As an example: I consider myself a C++ programmer but I wouldn't
choose C++ for a substantial GUI project these days. Not because of
the language but because of availability of GUI libraries.

 

[jimxoch]

....

With regard to surveys, I think they are no replacement for
lessons learned from years of experience. Moreover, there is no
guarantee that just because most people use one approach, this is the
right one, or that it is the best one for the particular circumstances
one faces.

I agree and I have no intention to use this survey as a guiding rule,
however I do consider such a survey very interesting, because of two
reasons:

1. In case the survey confirms the internet discussions and not what I
am experiencing, it is interesting for me to find out why do I have
such a wrong impression about the other programmers.

2. In case the survey results are very different from what most of the
internet discussions assume, this will be a very interesting paradox
and I love paradoxes, since investigating them might lead to very
important findings.

Of course there is always possible for such a survey to have
inconclusive results...

Best regards,
Jim Xochellis

 

[jimxoch]

Don't try to think that there is a simple answer to that.
Optimizations are still required in software like games, but
I think premature optimization is not common in professional
development.

At first I was sure that a relative survey should definitely exist.
Now I am not so optimistic...

Best regards,
Jim Xochellis

Homepage: http://jimxoch.freehost.gr/

 

[jimxoch]

I think if you asked, most people would probably say that
everybody else optimized to early or too late; they themselves
optimized just enough at just the right places.

The truth, however, is probably that results depend on the
environment where they are created.

I am not a professional programmer, but work in an enevironmet
where time is scarce and pressure to deliver results is high.
Much like - according to some people's claims - the programming
business.

My impression is that people in this kind of environment just
don't think. There is little planning or prioritazion of tasks.
Instead, people tend to react to stimulus: Whoever shoutest
loudest that "quit what you're doing and get *this* done ASAP!!"
will get their tasks moved to the top of the to-do list. Not
necessarily done, but moved to the top.

This is not at all a good environment for creating Great reults
in my day job, and I doubt if it is in programming.

Rune

Thank you Rune. I certainly share some of your impressions, but their
are still your/our impressions. I hope in finding something more
objective...

Best regards,
Jim Xochellis

Homepage: http://jimxoch.freehost.gr/

 

[jimxoch]

....

@OP: Sorry Jim, I have no idea about the existence of surveys and
alike, wrt your original topic.

Thanks anyway. Hope dies last

Best regards,
Jim Xochellis

Homepage: http://jimxoch.freehost.gr/

 

[jimxoch]

....

The answer varies widely if the software developers are writing
applications, libraries or operating system layers. The two lasts are
much more demanding since interfaces cannot be changed easily once
"published".  Anticipating all cases of use is difficult which means
that components must be optimized somehow to fulfill the full range of
"possible" use. This could lead to a significant amount of extra work
comparing to the development of applications where the domain of use
is better known and controlled.

Thank you for answering. Any surveys that you might know?

Best regards,
Jim Xochellis

Homepage: http://jimxoch.freehost.gr/

 

[robertwessel2]

Translating a complete, non-trivial program from a language to another
isn't exactly child-play and if a program has the chance of _needing_
to be implemented in a language, choosing another in first place is
not a "premature pessimization", it is a "serious project management
flaw", in my opinion.

While you said "complete," I think it's worth pointing out that
prototypes can often be usefully written in languages other than the
final implementation language. In situations where significant
uncertainly about the design exists, and a prototype is justified (and
frankly that's true in reality far more than happens in practice), the
prototype should be written in with a tool that make it easy to write
and modify (in the short term), while possibly ignoring many other
factors (like deployment and performance). A decided advantage of
using a different (and impractical to deploy) language is that you
don't end up with management insisting you turn the prototype into
production code.