[Etoys] etoys performance problems

[Ties Stuij]

He lists (crossposting to Etoys and Squeak dev due to relevance for both),

One can say that I am sort of taking over from Luke (Gorrie) as OLE
Nepal's Etoys performance optimizer (optimizator?). And I'd like to
give a status update, but I would especially like some advice on some
issues.

And the sooner the better. Cause we at OLE Nepal are in dire straits;
we've got major performance issues, some of which are Etoys related,
and some of which are Squeak related. And the reason for the speed is
that we're gonna have to have a working XO build in a few days cause
we have to train teachers, and in te beginning of April we're gonna
flash a build to the machines of the children of the pilot schools,
who will use it in the classrooms. So without further ado, except for
this redundant sentence:


project loading

To start with the known, I've been looking into the project loading
times, and have managed to cut them in half by removing the gzipping
on the project files and just using the .pr file in stead of the zip
which claims to be a .pr. Now this might of course not be the perfect
solution for all, I did uncover some practices on which I'd like
either the opinion of Squeak people in general or that of the Etoys
people in particular.

First, I noticed (together with Luke, who showed me the debugging
ropes) that in the method asUnzippedStream, on ReadWriteStream, the
method upToEndWithProgressBar uses '/' an awful lot to give the the
right approximation to the progress bar. It sucked about 20 percent of
the total loading time of an activity. So I changed
upToEndWithProgressBar for upToEnd. Which seems like a more reasonable
default 'cause I'd guess that usually one won't actually use the
progress bar functionality.

But thats not the end of it Etoys-wise. 'Cause it turns out an Etoys
project file is gzipped twice. First the individual file in
'writeForExportWithSources:inDirectory:' and then the containing
function writeForExportWithSources:inDirectory: as part of the .pr
bundle. And this for a file that already has lots of it's contents
compressed, seeing that most of the project file is taken up by jpegs.
And this would ideally also be the case for sound files, but more on
that later. The size decrease due to zipping in general is not more
than 10%. So my question on this topic is: is there an argument for
retaining the double zipping? And would there be a general need for a
'just save an uncompressed .pr file, instead of a bundle'
option/patch?


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.

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

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?


Sound format

Another strategy to trimming down the image size is using a compressed
sound format. At the moment we use wav for sound right? If I'm wrong,
excuse me, but I haven't had time to investigate the matter to
thourougly. Anyways, since a number of activities have quite a few
samples in them, ranging from short utterings to long sentences, it
would be very worth while if we could use a compressed format. From
the mailinglist I read rumours about Ogg plugin and a gstreamer
plugin... Is it already possible to use Ogg files in Etoys? If so how?
I'd already be happy with general directions.


Well that's perhaps a bit more than quite enough questions for one
post. I'll save some for later. It goes without saying that any advice
on these topics would be greatly appreciated.

/Ties