> Looks like at least one problem is that we do a linear
> lookup when searching for an interface by if-index.
Absolutely correct. I am well aware of this issue
and my intention was indeed to add an internal map to IfTree
similar to what you suggest below.
FYI, this method (and few other related methods) were added during a
recent FEA refactoring and the initial emphasis was on correctness.
Obviously, with the much smaller number of interfaces the rest of us
we have to deal with, the performance optimization wasn't an urgent
priority.
In your implementation you need to be very careful that you capture
all places inside IfTree that are related to the new pif_index to
vif mapping.
Thanks,
Pavlin
> IfTreeVif*
> IfTree::find_vif(uint32_t pif_index)
> {
> IfTree::IfMap::iterator iter;
>
> //
> // XXX: Find the first vif that matches the physical index
> //
> for (iter = _interfaces.begin(); iter != _interfaces.end(); ++iter) {
> IfTreeVif* vifp = iter->second.find_vif(pif_index);
> if (vifp != NULL)
> return (vifp);
> }
>
> return (NULL);
> }
>
>
> So, when reading in 600 interfaces, and then 600 addresses,
> it adds up quickly.
>
> I think the first thing I'll attempt is to add a second map
> mapping the if-index to a pointer to the IFTreeVif object
> found in the IfTree _interfaces map. Hopefully the hash will be significantly
> faster than the linear search through the name -> IFTreeVif hash...
>
> The complete oprofile report for the xorp_fea binary is here:
>
> http://candelatech.com/oss/fea_oprofile.txt.gz
>
> Thanks,
> Ben
>
> --
> Ben Greear <[EMAIL PROTECTED]>
> Candela Technologies Inc http://www.candelatech.com
>
> _______________________________________________
> Xorp-hackers mailing list
> [email protected]
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
_______________________________________________
Xorp-hackers mailing list
[email protected]
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
