[olsr-dev] olsrd profiling session

Andreas T√łnnesen (spam-protected)
Sat Feb 26 21:48:32 CET 2005

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

More information about the Olsr-dev mailing list