[Xorp-hackers] More ideas for xorp code size improvements.

Bruce Simpson bms at incunabulum.net
Thu Apr 15 11:45:15 PDT 2010


On 04/15/10 19:26, Ben Greear wrote:
> On 04/15/2010 09:10 AM, Bruce Simpson wrote:
>> On 04/15/10 07:48, Ben Greear wrote:
>>> ...
>>> I'm not too sure.  It might be that horribly complex template
>>> thing that builds callbacks methods.  If I were to tackle it, I'd
>>> probably change some callback signatures to pass in const string&
>>> and then see what broke and try to work backwards from there...
>>>
>>
>> Futzing with 'string' might be a noop, because many STL implementations
>> ref-count the internal string representation (GNU libstdc++ does, for
>> example).
>
> Yeah, looks like it wouldn't save much..but would still save a little,
> and should be cleaner code.

I'm not sure what you mean by cleaner code here.

It's difficult for me to assess this further without seeing sample code.

>
> There might be other areas where we are passing stuff by value that
> could be const foo& as well..but I haven't looked hard.

I'm deeply concerned that XORP is still not API-stable enough to be used 
commercially.

Changing what is generated for XRL, is effectively changing a published 
API, although XORP has never really had a policy on this; common sense 
needs to prevail. With the Thrift work (suspended), I was looking to 
shim at the level of that API, to avoid introducing piecemeal changes 
across the tree.

XRL send methods are pretty trivial (and I believe already constified). 
XRL recieve callbacks are not so trivial, because they potentially need 
to validate unmarshalled arguments.

Input arguments are generally passed by value (and constified) already. 
Output arguments are passing values back to the glue wrapper which 
invokes them. They are then responsible for output marshaling. As a 
side-effect, they can't be const and remain references; they'd have to 
become pointers.

This is a side-effect of delegating marshaling to the XRL layer, rather 
than doing it directly. Any RPC layer (CORBA, RMI etc) generally behaves 
like this.

To get more background on XRL, please refer to my Thrift related posts 
on this list from the XORP, Inc era.

The usual practice for profiling code size changes, in static binary 
footprint, is to use 'nm' and 'size' a lot. You can profile RSS at load 
time using Exmap. If you're looking for a source to crib scripts from, 
please see my posts on the Apache JIRA thrift-users list from around 4 
months ago.

regards
BMS



More information about the Xorp-hackers mailing list