[Etoys] etoys performance problems

[Ties Stuij]

>   I'll try to modify the code so that .pr file may not have to be
 >  compressed and see if how much we gain.

 Ah nice, that happens to be what I'm working on as well.
 I've got some patches to play around with which disable either zipping
 the project file or the bundle, and subsequently only delivers the .pr
 file (Oh, the confusion, naming both the project bundle as well as the
 project file <pr-name>.pr).

 Hopefully tomorrow I'll give an account of my performance findings
 while testing different combinations of zipping. As an intermediate
 report, totally unzipping a .pr file almost doubles loading on my mac,
  but loading on an XO has  been slightly disappointing. Small projects
 were up to 2 times as fast to load, but the bigger ones were a quarter
 as slow.

 Attached are some other patches related to zipping:

 1) fileIn fix
 In order to load a project bundle with an non-zipped .pr file in it,
 you've got to change the type of stream to create in
 projectStreamFromArchive from RWBinaryOrTextStream to
 MultiByteBinaryOrTextStream, since that's the class the project
 loading methods are defined on.

 2) asUnzippedStream
 changes uptoEndWithProgressBar to uptoEnd in the method with the same
 name as the changeset to get a 20 percent increase in project loading.

 These patches are part of my 'one patch per day' project, that will
 run from now till into the not at all to distant future.

 /Ties
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fileIn fix.1.cs
Type: application/octet-stream
Size: 553 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/etoys/attachments/20080408/d9e03f7f/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asUnzippedStream.1.cs
Type: application/octet-stream
Size: 1023 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/etoys/attachments/20080408/d9e03f7f/attachment-0001.obj