[Etoys] [squeak-dev] etoys performance problems

[karl]

Ties Stuij wrote:
> 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?
>   
Sounds like you are onto something. There are some dark corners in the 
project saving and loading classes and it needs some tlc.

>
> 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.
>   
Ogg and speex should work. There is a Ogg plugin and supporting classes 
for handling the sounds.
I made a sound library tool that let you compress the sounds in 
different codecs once they are imported into Etoys.


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