Re: [Pharo-dev] Implementing lazy loading for expandable collections

On 20.09.2014, at 14:27, Alexandre Bergel <alexandre.bergel@me.com> wrote:

Hi Max!

Thanks! This is something I wanted to push to Pharo for a long time. A simpler approach, would be to initialize the internal array to #() when initialized per default. This will provide pretty much the same benefits, and will not break the existing tools.

Does this make sense to you?

I think that would work well for standard use cases with #new. However, it wouldn’t work for explicit size requests. The question of course is, how often will a collection be created with an explicit size and *still* stay empty. I guess you would know that better than me. I opted for the other solution because I didn’t want to change the meaning of #new (which is to request a default size of 10) and because I simply assumed that even collections with explicitly requested size could stay empty. In terms of simplicity I like you’re idea far better of course :) It also makes a lot of changes moot that are necessary to initialize the array when required, because the array will simply be grown. What do your measurements say? Cheers, Max

Alexandre

...

Le 19-09-2014 à 2:35, Max Leske <maxleske@gmail.com> a écrit :

I’ve written an implementation of lazily initialized expandable collections (for OrderedCollection and subclasses only for now), inspired by Alexandre’s talk at ESUG (http://www.youtube.com/watch?v=x0YJ2dsZdKg&list=UUO-vBhaKVZf0al-ISMMPvRw). The implementation is pretty much straight forward but there are a couple of culprits I want to point out in case anybody else wants to do this:

- my implementation requires an extra instance variable in OrderedCollection to store the requested size. This extra instance variable will break Monticello (and possibly other tools) because Monticello uses OrderedCollections to load code and the particular way it uses them makes it impossible to change the number of instance variables on OrderedCollection. Also, all .mcz files written after the change will not be loadable by images without the new instance variable (same reason). - the above means that you have to modify the code in the image manually and save a new “base image" - read only messages should obviously not initialize the array. The ‘firstIndex’ and ‘lastIndex’ variables are quite handy for that. I initialize those variables to 1 and 0 respectively which makes most things work already (e.g. #size, #isEmpty etc.). - when trying to implement the same for HashedCollection I couldn’t. The image didn’t just stop working, there was no output at all on the console, not even when using a debug VM. The problem seems to be MethodDictionary, at least that’s the only subclass of Dictionary for which adding an instance variable doesn’t work.

I’ll share some memory monitoring as soon as I have something significant (only just rolled it out).

Big thanks to Alex for his talk and the cool work he and his students did!

Cheers, Max