On 07/05/2013 05:02, Marvin Humphrey wrote:
We might want to introduce String as a subclass of CharBuf with all of the
mutability disabled. That makes it easy to break up monolithic interconnected
webs of CharBuf usage into bite-sized chunks when switching over. Once the
transition is complete, we can remove the inheritance.
Yes, this might be helpful.
That's true, but I still imagine stack wrappers are a win in the aggregate.
(I wish I could quantify that assertion.) It's very common to pass simple
strings: field names, hash keys, query strings, file names and file paths,
user names, URIs, etc.
My guess is that there will be a win, but that it's smaller than it
might look. Some examples:
* Hash keys: No copy needed if used to fetch from a hash. If used to
store, they must be cloned.
* Field names: No copy needed if used as hash key like in
Schema_Fetch_Type. Will be copied in constructors like
SortRule_new, Highlighter_new, *Query_new.
* Query strings will need iterators, so a copy will be made.
* File names and paths won't have to be copied mostly.
So in many cases a "zombie" string has to be copied anyway defeating the
whole optimization (even costing a bit). But, as you say, it would be
nice if this could be measured.
I think that exceptions may longjmp out of Clownfish code past the host
wrapper, though. Right now if that happens we can leak memory -- a newly
allocated Clownfish object needed for calling into Clownfish code may not get
decremented. If we delay copying we might start getting memory read errors,
though.
Right. The lazy copying won't work with longjmps.
Nick
