Re: [gobo-eiffel-develop] Memory allocation overhead

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> But I'm interested in what approaches/techniques you use to avoid
> extra allocations.
> 
> Do you use free at all? Obviously that won't reduce the number of
> allocations, but it will reduce the number of objects the GC has to
> deal with. Does it give any advantage over assigning Void to the
> reference?

I don't use free.

> Expanded attributes? This implies having default_create as a creation
> procedure, whereas the Gobo standard is to have an empty make.

I don't use expanded.

> Another possibility is to avoid OO techniques. For instance, I know
> from last weekend's profiling that there is a VERY large number of
> XM_XPATH_UNTYPED_ATOMIC_VALUE objects created by conversion from
> XM_XPATH_STRING_VALUE. Untyped-atomic is XPath's coercible data
> type. Although untyped-atomic does not inherit from xs:string in the
> XPath type hierarchy, I have implemented XM_XPATH_UNTYPED_ATOMIC_VALUE
> as inheriting from XM_XPATH_STRING_VALUE for convenience, as they are
> nearly identical excpet for the coercing behaviour. So a clear saving
> could be made by merging the two classes with a BOOLEAN to indicate
> which type is actualy meant. Then the coercion to xs:string is simply
> implemented by flipping the BOOLEAN. I suspect this is going to be a
> big saving, but it is very anti-OO.

This might be the kind of things I could use indeed. Otherwise I try
to be very careful with strings. String concatenations and substring
operations create a lot of intermediary objects. Be careful as well
when strings get resized (even implicitly by some operations). Likewise
with DS_ARRAYED_... classes: try to create them with a capacity which
is not too big but not too small to avoid too many resizings. I know,
it's often not easy to choose the best capacity at creation time!
I also try to share objects as much as possible. Of course, when
shared, we have to be very careful that these objects don't have
their state modified. When that happens, then we need to clone it
beforehand. I use a lot of shared objects for the tokens when generating
the ASTs in gec. Another technique that I use is to try to reuse
objects, rather than giving them back to the GC and creating new
ones right after. In gec, I have AST visitor classes to implement
the different Eiffel "Degree" compilation passes. They all try to
keep the intermediary objects that they need to process a given
imput class. They reuse these intermediary objects when processing
the next input class, and so forth. I probably use other techniques,
but it's already a good start. One thing to remember is that when an
implementation technique is not "very" OO, try at least to make it
look as if it was OO in the class interface.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com