Re: Performance of NS

[Polly Huang <huang@tik.ee.ethz.ch>]

On Thu, 10 Feb 2000, Wei Tsang Ooi wrote:

> Hi,
> 
> Is anyone working on improving the performance of ns ?
> 
> IMHO, a lot of design decisions in ns are made to allow
> rapid-prototyping but not high performance.  As a result,
> ns crawls when the simulated network is large.
> 
> Below are some ideas I am exploring, but I am not familiar
> with ns enough to make any changes and still be sure that
> no others will be affected.
> 
> - profiles the otcl code in ns, and identify bottlenecks.
>   it should not be too difficult to insert code into otcl
>   to see how many times each Otcl instproc is called, and
>   how long each call takes.  

Wei,

I'm not sure if this is still working.. or on all the os/platforms..

'$ns clearMemTrace' is what i used to use to profile memory and runtime
usage.  Insert this in between the section of program you're 
investigating. It should tell the amount of heap memory, stack memory,
system time, and user time used for the particular section of code.  But
that inlcludes consumptions by involving C++ code as well.

> 
> - optimizes the bottleneck somehow.  For example, I believe
>   "set" and "instvar" are the most common calls.  Is there a
>   way to speed these up (like by-passing the lookup) ?

We tried to eliminate some of the bottlenecks, such as using delay bind
for mirrored variables.  John and Park are following up on this, I think.  

> 
> - can some of the otcl code be moved into C++  space ?
>   For example, Node::add-route is called O(n^2) time
>   in Simulator::compute-flat-route, and is a major bottleneck
>   in start-up time.

Yes.  Node::add-route is to setup cache entries in the node classifier
after all routes are computed after computer-flat-route.
Please keep in mind that each ns node is designed initially to mimic a
real network node wher they keep kernel level route entry cache.  You can
think of 'compute-flat-route' is the user-level route computation and
'add-route' is to install these computed routes into the kernel space.   

This part of code is not only time (as you've identified) but also memory
consuming (same N^2 routing entries are stored twice in different places),
and we've actually done eliminating this bottleneck with the Virtual
Classifier code. There's an example in tcl/ex/virtual-classifier.tcl.
The basic idea is to by-pass 'add-route'. Each node's classifier_
directly links to the routing data structure by 'compute-flat-route'.

Just like in a real network node, we go one step indirect (with the
Virtual Classifier), if a node has to classify many packets, the overhead
of going one step indirect will add up and the simulation performance
could get worse. 

> 
> - plain and simple code optimization.  For example, the current
>   Timer class (tcl/mcast/timer.tcl) makes many redundant calls
>   to "$ns cancel $id".  Also, we should be able to make 
>   RouteLogic::compute_routes() run faster.

I'm not quite familar with the timer code.  If removing some of these
cancel events doesn't result in memory leak (which is a big no no :), then
I'm all for it.  Like Hoabo said, any patches/fixes are welcome!!

Cheers,
-Polly

> 
> Any comments ?
> -- 
> ______________________________________________________________
> weitsang@cs.cornell.edu  System Lab, Upson Hall (607) 255-0102
>