On Wed, 2007-08-15 at 08:57 +0200, Sven-Ola Tuecke wrote:
[...] 
> while attending the 2007 CCC's summer camp in Finowfurt, I investigated a
> bit the wireless terrain. Situation was unique, because we normally do not
> have ~ 30..40 OLSR nodes in near range.

Cool:-)

[...] 
> http://download-master.berlin.freifunk.net/sven-ola/gmon.txt
> 
> To my interpretation, olsr_input_lq_tc() is a good candidate for further

JftSoC: Since (sufficient recent) gccs automatically inline functions
called only once (if they are defined before the call),
deserialize_lq_tc(), process_lq_tc() and destroy_lq_tc() cannot be found
in the above file.

> optimization. Every incoming LQ_TC will trigger a lot of mallocs (in this
> situation for each neighbour included in the message one malloc). After
> sending the unpacked LQ_TC through processing, the data is freed again.

Uuugh, it's even worse;-):
- In deserialize_lq_tc() we malloc a list of "struct lq_tc_neighbor".
- In process_lq_tc() we malloc a list of "struct tc_mpr_addr" and fill
  it with the (almost the whole) contents of the former "struct
  lq_tc_neighbor".
- And in destroy_lq_tc() we free the "struct lq_tc_neighbor" list again.

Given the copying of the list elements in process_lq_tc(), 
struct lq_tc_neighbor and struct tc_mpr_addr are identical except for
the name of the fields.

So the obvious first thing to do (earning at least the low hanging
fruits) and save approx. 50% of the malloc()s and the same number of
free()s of course and remove some useless code is to kill "struct
lq_tc_neighbor" and create immediately the final list (of "struct
tc_mpr_addr"s) in deserialize_lq_tc() as in the attched patch.
It works for me!

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services
