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

[Daniel T. <dan...@gm...>]

Eric Bezault wrote:
> 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
This kind of information is very interesting in my opinion. But I never 
read something comparable. I am not sure if you have a long term plan to 
use http://gobo-eiffel.wiki.sourceforge.net/, but I would be willing to 
publish it there. Is that ok?