[olsr-dev] olsrd profiling session

[Sven-Ola Tuecke]

Hi Andreas, Thomas, Bruno,

in the Berlin mesh I experience a high CPU load, needless to say that we use 
the latest CVS version with LQ=2. On my standard notebook, this is not a 
problem, but on the much slower WRT54g devices, it is. CPU load is now 
between 50% and 90% all the time.

So I hacked a bit for investigation. I attach my profiling output to this 
mail, made on my notebook (profiling does not run on cross compiled version, 
sorry). The results in brief:

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. 

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.

My changes are diffed in the olsrd-hack.diff.txt. The last file is a gdb 
backtrace copied while encountering a namespace-plugin-SEGV. 

@bruno: I investigated for the namespace plugin also. The main "name-receive 
function" only compares *one* name in update_name_entry() for(entry) loop if 
names are received. If the name is already known, the compared name match 
instanly due to the hash mechanism. But I expected some more printf()s to 
show up for new unknown names. (I inserted a debug-printf into that for() 
loop) Is that for-loop O.K? Or is it pointer-does-not-point-to-right-obect 
here?

Regards,
Sven-Ola
-------------- next part --------------
A non-text attachment was scrubbed...
Name: olsrd-profilesession.tgz
Type: application/x-tgz
Size: 27937 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20050226/a88e7919/attachment.bin>