Hello Tie,
Your email is very interesting. And I am wondering: does jpeg file inserted in a Squeak image then saved in a .pr file are saved in the .pr file as jpeg data or just 24bits RBG form data? I am enclined to think this is the second option, if so the size impact is hudge.
With your project growing, you may want to stop using .pr file and use external file to describe the activity (xml files) plus media data (jpeg, ogg, etc.). I am betting you will see a hudge performence boost. But then you are cut from Etoys..
I am currious to read Squeak friends advices.
Hilaire
2008/3/25, Ties Stuij cjstuij@gmail.com:
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 _______________________________________________ Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys