Re: Iterating a std::vector vs iterating a std::map?
On Nov 24, 5:57 pm, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
James Kanze <james.ka...@gmail.com> wrote in news:5cdb6f3a-e2e0-48c1-
9080-cc35f58e1...@1g2000vbm.googlegroups.com:
On Nov 24, 7:06 am, Paavo Helde <myfirstn...@osa.pri.ee> wrote:
"carl" <carl@.com> wrote innews:4b0b34ea$0$280$14726298
@news.sunsite.dk:
If the code still seems too slow, then one should use
profiling to see if there are any unexpected bottlenecks. You
cannot rely on profiling only, because if you write uniformly
unefficient code all over the place there will be no
bottlenecks.
Sure there will. The code which is executed most often will be
the bottleneck. You can generally start by not worrying too
much about efficiency; if you've encapsulated correctly, there
will then be no problem improving the efficiency of the places
which really are bottlenecks, i.e. the places which are executed
the most often.
Yes, *if encapsulated correctly*, there is no problem.
However, I'm afraid that the people writing unefficient code
are not very proficient in things like encapsulation, either.
Yes. People who write bad code will write bad code:-). They
have to be taught. But it's easy to check for proper
encapsulation during code review. On the other hand, it's
almost impossible to see where the bottlenecks will be until
you've actually measured. (At the lowest level, at least.
Obviously, if someone's used an O(n^2) algorithm, and you know
that there will be millions of elements to deal with, you don't
need the profiler to know that it's not going to work. You
should catch things like that in code review as well.)
An example would be that somebody writes all over the place:
A* a = new A();
a->f();
delete a;
If operator new pops up in the profiler, it is not clear which
use cases are legitimate, which are not, and fixing the
problem is not so simple as it must be done in many places. If
it does not pop up in the profiler, it just makes the program
slower by few percents and nobody ever fixes it. If there are
many such things, these few percents are all added up...
The problem above is deeper. C++ supports value operations, and
a programmer who doesn't use them needs to be taught C++. It
has nothing to do with performance (at least not in the first
line); it's a question of semantics. The difference between:
A* a = new A();
a->f();
delete a;
and
A a;
a.f();
isn't just performance---it's also number of lines of code
written, what happens if an exception is thrown, and what
happens if (later) someone assigns a to another variable (of the
same type). And all of those issues are more important than
performance, since they affect program correctness and
maintainability.
(In most languages, for a variety of reasons, doing things the
idiomatically correct way will result in better performance,
over all. In C++, this is particularly true. But in all cases,
the reason for doing them in this way is because it is the
idiomatically correct way, and not for performance reasons per
se.)
--
James Kanze