[olsr-dev] olsrd profiling session

[Sven-Ola Tuecke]

Hi Andreas,

the profiling version was compiled without -DDEBUG. So I belive it's the
olsr_printf("results %s", cpu_intensive_func_returns_string()) which eats up
CPU time even of not -DDEBUG. So I suggest a change to:

if(0<debuglev) {
  olsr_printf("results %s", cpu_intensive_func_returns_string());
}

I excluded the olsr_printf() just as a side effect when profiling, because I
need to run with -d1 to have correct pmon.out (pmon.out has no time infos if
olsrd runs in background and gets terminated with kill -HUP). Maybe its
possible to add a -F switch for "do not fork()" for convenience here.

P.S.: I encounted OLSR packets with more than 1400 bytes here. I've seen
Thomas - who reads that binary -dispin stuff without glasses ;-) Is there by
chance a place where I can read about the binary message format?

Rgds, Sven-Ola

----- Original Message ----- 
From: "Andreas Tønnesen" <(spam-protected)>
To: "OLSR development" <(spam-protected)>
Sent: Saturday, February 26, 2005 9:48 PM
Subject: Re: [olsr-dev] olsrd profiling session


> Hi Sven-Ola,
>
> Thanks for an interesting mail.
>
> > a) Most CPU load goes with olsr_prinf() which is active even with -d 0.
Only
> > the output is suppressed, but redefining olsr_printf() to nothing will
lower
> > the CPU load to acceptable 20%. olsrd.profile1 is made with this
version. I
> > suggest surrounding some of the central CPU intensive debug stuff with
> > if(debuglev) { olsr_printf() } or similar.
>
> Most higher level debug output calls are defined out if DEBUG is not set
> just for the reasons you mention. I think we might create a symbol that
> can be defined (NODEBUG or something) that will not include any output
> calls(except the most essinsial ones). I think I'll do a cleanup of what
> output calls that belong in non-DEBUG defined code. Perhaps we should
> even add a macro OLSR_PRINTF that does what you suggest. I'll do
> something about it :)
>
> > b) Then I checked further with several replaced mini-functions called in
the
> > LQ code. I was not sure, if the compiler optimizes that mini-functions
to
> > inline code, so I give it a try. This is olsrd.profile2 - the
inline-replace
> > do not have very much effect.
>
> Remember that inline functions must be visible to the compiler at the
> function call for inline to have any effect. So if the functions reside
> in other object files inline will not have any effect as far as I can
> remember. Perhaps this is why you saw little effect? Then again it might
> just be because gcc does efficient optimizations already I guess.
>
> - Andreas
>
> -- 
> Andreas Tønnesen
> http://www.olsr.org
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
>