[Xorp-hackers] oprofile reports

[Ben Greear]

I'm running 100 xorp instances on a dual-quad core system (E5530, 2.4Ghz)

I let them run a while, which tends to hide the xrl stuff that is mainly
a startup cost.

This is my patched tree, by the way.

FEA is the top entry on the entire OS (but, there are 100 FEAs running, so that's not un-expected)

At least in my code tree, the get_ready_priority is a couple of for loops..and
could probably be optimized, to better ignore fds that are not in use.

samples  %        image name               app name                 symbol name
-------------------------------------------------------------------------------
   22        0.0766  xorp_fea                 xorp_fea                 EventLoop::do_work(bool)
   28687    99.9234  xorp_fea                 xorp_fea                 SelectorList::wait_and_dispatch(TimeVal&
)
27759     6.5897  xorp_fea                 xorp_fea                 SelectorList::get_ready_priority(bool)
   27759    99.6196  xorp_fea                 xorp_fea                 SelectorList::get_ready_priority(bool) [
self]
   54        0.1938  xorp_fea                 xorp_fea                 SelectorList::do_select(timeval*, bool)
   52        0.1866  xorp_fea                 xorp_fea                 std::vector<SelectorList::Node, std::all
ocator<SelectorList::Node> >::operator[](unsigned long)

Nothing else really stands out, except that we are probably creating and deleting a lot
of strings (or something else with an underlying vector in it), which calls memset.

I can't tell from oprofile what the call chain for the memset usage is though,
will look for other ways to get at that...

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com