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

[Colin P. A. <co...@co...>]

>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:

>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    Eric> You can try reducing the amount of garbage generated

    Colin> So as an example, in XM_XPATH_STATIC_PROPERTY, I have four
    Colin> ARRAY [BOOLEAN] which are included in every
    Colin> expression. Presumably it would be much cheaper to remove
    Colin> the booleans from the arrays (I can't think why I put them
    Colin> in ARRAYs in the first place).

This seems very productive. I changed the first two arrays to be just
a series of BOOLEANs, and the runtime came down from 71 minutes to 50
minutes (my target is sub-one-minute, so there's a way to go, but it's
a good start).

So I'll do the other two ARRAYs next.

Another possibility is actually  to merge all the BOOLEANs as a
bit-field. This will save memory but not the number of objects, so I'm
not really interested in doing this. It might hurt performance.

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?

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

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.
-- 
Colin Adams
Preston Lancashire