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 _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
