[Ns-developers] A Reason for Slowness of NS3

[Mathieu Lacage]

On Sat, 2009-02-14 at 23:43 -0500, Adrian Sai-Wah TAM wrote:
> On Sat, Feb 14, 2009 at 11:30 PM,  <craigdo at ee.washington.edu> wrote:
> >> static TypeId Class::GetTypeId()
> >> {
> >>     static TypeId tid = ....;
> >>     return tid;
> >> }
> >
> > Isn't there a mechanism for optimizing exactly this situation?  Return Value
> > Optimization (RVO) or in this case, Named Return Value Optimization (NRVO)?
> > Hasn't this been in gcc since release 3.something?  Doesn't this
> > optimization already elide the "extra" copy construction that we're
> > discussing removing?  I'm not following this thread in great detail, but
> > isn't this particular case a solved problem?
> Well...I am not a GCC expert, but if there is RVO, it should be the
> case. Since I don't do optimization when passing things to gprof, I am
> not sure if I input -O3 to gcc can reduce the number of calls.

Then, the output of gprof is irrelevant. Generally, gprof can't be
relied upon very much because it is _intrusive_ (it modifies the code
generated) and its use makes it much harder for gcc to use various
optimization techniques so, enabling gprof will disable various
optimizations, maybe RVO itself in this case.

> > I must admit I'm getting a little confused about what exactly is being
> > suggested and measured ...
> In short, I suggested to do a tedious scan on the source code to
> change class object as argument in function calls into const reference
> as argument.
> 
> Some update: I found another potential candidate for converting
> objects into references is the events in a scheduler. In the Invoke()
> call, a significant amount of time is spent in MakeEvent<..>() calls.

Again, I find it very odd that you focus on this kind of problem when
there is a much bigger target for optimization and when that target will
most likely change heavily the behavior of very small functions called
very many times. What you are focused on really makes little sense
because:

  - once you use a non-pic build, the profile and behavior of the code
will change drastically, especially for the kind of very small templated
functions you are looking at.

  - it makes zero sense to focus on really small micro-optimizations
_before_ dealing with bigger optimizations. This does not mean that
micro-optimizations are useless. It means that they should not be
considered before dealing with the bigger optimizations because the
bigger optimizations will change the kind of micro-optimization which
make sense.

regards,
Mathieu