Re: inlining virtual functions
Francis Glassborow wrote:
In article <1149237752.446336.237810@j55g2000cwa.googlegroups.com>,
kanze <kanze@gabi-soft.fr> writes
I said cheapest, not most effective:-).
If the profiler shows that I have a performance problem in a
specific place, and the problem is small enough that an
incremental improvement might suffice, the first thing I'll try
is inlining -- I'd much rather deal with the extra compile time
dependancies than with a twisted way of writing code. And
obviously, since optimization is always done using the profiler,
if the effects are negative (which as you correctly point out,
can happen), then I'll see it immediately, undo the change, and
look for some other solution.
The problem is that the performance is heavily tied to the exact
hardware the program is running on.
Certainly. But if you've seen a performance problem, you've
seen it on a specific hardware.
There is, of course, the possibility that your optimizations on
that platform slow the code down on some other platform. If
they slow it down too much, you will end up having to either
find a different solution to the optimization problem, or
maintaining two versions. (It's already happened to me.)
I am sure you know the problem and regularly profile on the
most restricted hardware the program might run on,
Which is? You don't really know which machine will cause what
problem until you've profiled on it. Generally, I don't profile
at all, until there is a problem; that problem is always on a
specific machine, and obviously, that's normally the
configuration I profile on.
but many people are less careful, use high spec hardware for
development and then ship the program to run on other
hardware.
I'd say that that's standard procedure. Developers are your
most expensive resource; you do everything to make them as
efficient as possible.
Of course, you don't ship directly out of developpement.
There's integration, and quality assurance, and some other steps
in between. At the very least, quality assurance will test on
all possible configurations.
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]