[Xorp-hackers] Limitations for multiple instances of XORP

[Pavlin Radoslavov]

> What I can tell you is that the sizable runtime memory footprint is 
> going to have an effect -- the short answer is, try it and see. You say 
> nothing about the size of this machine you're running XORP on, which 
> XORP processes you are running, how you've built/linked them, so 
> anything here is pure speculation without real data.
> 
> But I've just had some coffee, so I'll wax lyrical.
> 
> ELF lazy symbol binding will probably have a negligible effect on 
> runtime performance, when executables are first loaded.
> 
> Sure, page sharing will be a factor at the single executable level, but 
> it's not the same as benchmarking the actual reduction in footprint when 
> shared libraries are introduced across the board, something I did last 
> year but haven't published.
> 
> I've done work on reducing this in build engineering land, by rototiling 
> for shared libraries, something which people don't seem to want to get 
> involved with ("Help me Obi-Wanken Autotools, you're my only hope") 
> judging by the burgeoning silence on the topic -- or, perhaps it's more 
> open source tragedy of the commons, what can we get for nothing this 
> week/month?

Yes, we agree that we want to start using shared libraries.
One of the motivation for the autotools refactoring/upgrade in XORP
was to make this transition easier. The main obstacle is scheduling
the transition and getting the cycles for the actual switch.

Thanks,
Pavlin

> [Cue slapstick humour]
> 
> The lack of progress is understandably so, given that the quality of the 
> freely available tools has only recently come to the point where doing 
> it for a moderately sized software project such as XORP, has been 
> feasible, i.e. Boost.Build.