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

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

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    >> 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.

    Eric> This might be the kind of things I could use
    Eric> indeed. 

It helped, although not as dramatically as eliminating my ARRAY
[BOOLEAN]s. Eliminating these 4 arrays takes the time down from 71 minutes
to 30 minutes. This change to the untyped atomic values brings it
further down to 22 minutes.

    Eric> Another
    Eric> technique that I use is to try to reuse objects, rather than
    Eric> giving them back to the GC and creating new ones right
    Eric> after. In gec, I have AST visitor classes to implement the
    Eric> different Eiffel "Degree" compilation passes. They all try
    Eric> to keep the intermediary objects that they need to process a
    Eric> given imput class. They reuse these intermediary objects
    Eric> when processing the next input class, and so forth.

Presumably you can only do this because you know when you have
finished with an object, and don't have to rely on the garbage
collector working out when it can free memory.

I don't know how many such cases I am likely to find. If I do, then
perhaps there is the possibility of doing memory pooling - allocating
a single chunk of memory for a large number of identical objects.

I'm not sure how to go about that in Eiffel. I would guess that if I
have a reference class C, with default_create as a creation procedure
(is that necessary?) then if I create an ARRAY [expanded C] the memory
will all be claimed in one call to malloc. Then if I can get a
reference to one of these objects (how do I do that in Eiffel?), I can
call the real creation procedure (it will need to be exported to the
calling class) to initialize the referenced expanded object. I then
just have to keep track of free slots for reusing the memory.
-- 
Colin Adams
Preston Lancashire