[Ns-developers] A Reason for Slowness of NS3

[Adrian Sai-Wah TAM]

On Sat, Feb 14, 2009 at 12:57 AM, Mathieu Lacage
<mathieu.lacage at sophia.inria.fr> wrote:
> Before I get to commenting this specific change, let me point out one
> thing which I think is very important: you have been using an optimized
> PIC shared library build. As I explained before on this mailing-list,
> this results in about a 40% wall-clock pessimization on every benchmark
> due to the use of an extra indirection jump for almost every non-static
> function call. If you can manage to build a static non-pic version of
> ns-3, you will see most likely a _very_ different performance profile
> with _very_ different functions on top.
Yes, I know. Actually I have a handful of ways to optimize NS3 a
little bit. Of course, I am looking for the possibility to boost the
performance by 50% or more but what I posted about >10M call on copy
constructor is just something sound strange to me at the first glance.

> Now, what I am trying to get to is that spending time on trying to
> figure out how we can enable static builds as widely as possible, or
> possibly instead use techniques such as the one which came up last time
> we talked about it on this mailing-list (see
> http://mailman.isi.edu/pipermail/ns-developers/2009-January/005182.html
> and
> http://mailman.isi.edu/pipermail/ns-developers/2009-January/005186.html)
> would be a much more useful contribution than trying to shave off less
> than 1% with micro-optimizations.
Agree. But why we can't just, say, besides having -d debug and -d
optimized in waf configure, we add -d static to that as well? This
sounds natural and consistent to me.

> 1) this kind of less than 1% performance improvement in within the noise
> of measurement (could you show average relative perf improvement
> together with variance for 20 runs to show proof that you are not
> playing with noise ?)
I didn't do this and I agree with you, 1% improvement is not a big
deal. But what I want to raise is that, a lot other instance of copy
constructors besides TypeId are called while reference can do the job.
Since allocating and releasing memory doesn't cheap, why don't we scan
the code for once to see if we can change something to make it more
economical?

> 2) returning a _reference_ from a function ? Holly crap, never, thank
> you.
True, it sounds weired. But look at this:
static TypeId Class::GetTypeId()
{
    static TypeId tid = ....;
    return tid;
}
Shouldn't this frequently-called thing be something read-only? If so,
I think returning a const reference is good. Of course, just returning
reference is dangerous but make it const shall be fine. (I believe)

> 3) transforming by-value input arguments to const reference input
> arguments ? Maybe.
Actually, before sending the original mail, I change just GetTypeId()
but keep all input arguments as-is but the number of calls just drop
by a few percents. Once convert the input arguments to functions to a
const reference, the number of call reduced by a huge amount.