[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