[Etoys] etoys performance problems

[Andreas Raab]

Ties Stuij wrote:
> On Wed, Mar 26, 2008 at 12:43 AM, Hilaire Fernandes <hilaire at ofset.org> wrote:
>> 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.
> 
> Hmm, yes interesting question. I didn't investigate, but judging from
> the amount of pictures compared to the file size, I guessed they were
> stored compressed in one way or another. Perhaps somebody with
> knowledge could shed some light?

It's compressed. When you load a form via Form>>fromFileNamed: the 
project's resource manager will remember the original bits (the jpeg 
file). Only if the reference gets lost (the file deleted, the image 
moved) it will use the uncompressed bits.

>>  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.
> 
> As am I,

I would not recommend going down this path if you're new to Squeak and 
don't know what you are buying into. The .pr files work because half a 
dozen people spent a couple of years to make all of this stuff work. 
You'd be pretty much on your own recreating this effort so unless you 
have sufficient resources just try to deal with the inefficiencies and 
leave the architecture alone.

Coincidentally, in your previous message you noticed the 
double-compression problem. What I would do is simply change the code 
slightly such that it uses zip with no compression (which is one option 
with zip files). This allows you to reuse the whole infrastructure 
without paying the price of compressing/decompressing everything.

Cheers,
   - Andreas