[Etoys] etoys performance problems

[Bert Freudenberg]

On Mar 25, 2008, at 18:46 , Ties Stuij wrote:
> So my question on this topic is: is there an argument for
> retaining the double zipping?

Don't think so.

> And would there be a general need for a
> 'just save an uncompressed .pr file, instead of a bundle'
> option/patch?

Possibly. Changesets welcome :)

> project deletion/memory growth
>
> Our second issue is related to memory growth within the Etoys image
> that's causing problems for the, let us say, memory-challenged XO.
> First of all we've got a, say, root project, which enumerates the
> activities which it reads from a few directories. In that root project
> we've got a script running that deletes child projects. Or it should
> anyway. The key method here is okToChange, which i guess is a bit of a
> misnomer. That is it's got a bunch of code in it that should remove a
> project and it's content from the image, but it doesn't. To make it
> concrete: we've got this script running in the root project:
>
> unloadActivitiesToFreeSpace
> 	Project current children
> 		do: [:t1 | t1 okToChange] "or okToChangeSilently, but okToChange is
> nice for debugging"
>
> But after removing a project, executing 'Project allInstances' shows
> that there is still a reference to the project and when one keeps an
> eye on the memory usage (with an OSX utility), we see that no memory
> is deallocated. So the image grows and grows.

Well, you also have to invoke the garbage collector (it will not kick  
in if there is loads of memory still usable). And the OSX utility  
cannot tell which memory is actually used. Look at the VM statistics  
(in the help menu).

> So my concrete question is: how can one for once and for all delete a
> project instance. I was hoping to at least find some generic
> deleteInstance method in the image, but I couldn't find one (I'm a bit
> of a Squeak newbie).

You need to find out what's holding onto the project, break that  
reference, then the garbage collector will do its job.

> Then it seems to me that the image grows quite fast in general. Is
> there some known garbage collection problem concerning Squeak or Etoys
> that I should know about? And related; when I'm gonna try and trim
> down the image size: any suggestions on where to start? Is there any
> known fat waiting to be caved off?

Certainly - though image stripping is an art that tends to become  
forgotten with todays gigabyte memory equipped machines.

You should start by looking at what is making your image larger than  
expected - SpaceTally>>printSpaceAnalysis might help.

- Bert -