Discussion:
etoys performance problems
(too old to reply)
Ties Stuij
2012-01-28 12:16:29 UTC
Permalink
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
John M McIntosh
2012-01-28 12:16:29 UTC
Permalink
Post by Ties Stuij
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.
When I was building the Sophie storage subsystem for OLPC I noticed
the OLPC "hard disk" uses a compressed file system. There is some
technical notes on this suggesting developers do NOT zip files because
this is pointless: Compress the file, then store on a compressed file
system.
On read then you use cpu time to uncompress the compressed file, then
uncompress the file. Waste of CPU time.

As a compromise Sophie documents depending on the platform
contain a zip file which contains uncompressed images and compressed
text,
or uncompressed images and text if we know the platform target is OLPC.

However I was not sure of the network impact of then passing
uncompressed
files around.
Post by Ties Stuij
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.
The progress bars interfere with the actual time needed to perform the
action, we had loading progress bars for Sophie documents but found
for small documents the act of showing the progress bar and updating
it could take 80% of the load time.
Post by Ties Stuij
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?
See comment above about not zipping JPEGS/image data that is
included in the ZIP file. We choose to store media (sound/video) in
a separate
media folder because it was pointless to unpack from a zip file on
need. However
this might not be possible when you want all the data in the zip file,
still you could
alter the code so that sound/video files aren't compressed by the zip
logic when
they are added to the zip file.


In Sophie we also have a ZIP file subclass because we found the ZIP
storage class
was rather inefficient for ZIP files with many members. For example
when you lookup
and manipulate a zip file member it scans an ordered list looking for
the member by name.
We altered that to use a dictionary.
Post by Ties Stuij
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).
There are programming tools in the image that allow you to see who is
holding
onto a project, I'll let someone else comment.
Post by Ties Stuij
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.
http://tinlizzie.org/olpc/OggPlugin/

I am currently working on a gstreamer plugin for OLPC via funding from
Viewpoints Research Institute,
and have a target completion date for the end of the month. This
plugin will let you build
gstreamer pipeline chains and run them, right now you can build a
pipleline to decode audio/video ogg files for
example and send the video to a X11 window and the audio to the
hardware sound player.

I also hope to have 'sinks' which let you import audio and video into
Squeak.

--
=
=
=
========================================================================
John M. McIntosh <***@smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
Ties Stuij
2012-01-28 12:16:30 UTC
Permalink
On Wed, Mar 26, 2008 at 12:32 AM, John M McIntosh
Post by John M McIntosh
When I was building the Sophie storage subsystem for OLPC I noticed
the OLPC "hard disk" uses a compressed file system. There is some
technical notes on this suggesting developers do NOT zip files because
this is pointless: Compress the file, then store on a compressed file
system.
On read then you use cpu time to uncompress the compressed file, then
uncompress the file. Waste of CPU time.
Of course, I remember now I read that somewhere, so that's yet another
layer of compression; nice. And yes, for our own projects I already
removed the zipping.
Post by John M McIntosh
See comment above about not zipping JPEGS/image data that is
included in the ZIP file. We choose to store media (sound/video) in
a separate
media folder because it was pointless to unpack from a zip file on
need. However
this might not be possible when you want all the data in the zip file,
still you could
alter the code so that sound/video files aren't compressed by the zip
logic when
they are added to the zip file.
Yes, well as mentioned above, the not zipping isn't a problem. Also
'cause we distribute Epaati in an .xo bundle we've already got a
single file for distribution; which is, I'd like to mention just for
poetic reasons, yet another layer of compression! And an Etoys project
file already houses all the content needed for your project, all of
which is loaded at startup. There might indeed be something to say for
loading on need though...
Post by John M McIntosh
There are programming tools in the image that allow you to see who is
holding
onto a project, I'll let someone else comment.
Ah, I'd very much like to know! Anyone?
Post by John M McIntosh
http://tinlizzie.org/olpc/OggPlugin/
I am currently working on a gstreamer plugin for OLPC via funding from
Viewpoints Research Institute,
and have a target completion date for the end of the month. This
plugin will let you build
gstreamer pipeline chains and run them, right now you can build a
pipleline to decode audio/video ogg files for
example and send the video to a X11 window and the audio to the
hardware sound player.
I also hope to have 'sinks' which let you import audio and video into
Squeak.
Excellent, thanks.

/Ties
Bert Freudenberg
2012-01-28 12:16:31 UTC
Permalink
Post by Ties Stuij
On Wed, Mar 26, 2008 at 12:32 AM, John M McIntosh
Post by John M McIntosh
There are programming tools in the image that allow you to see who is
holding
onto a project, I'll let someone else comment.
Ah, I'd very much like to know! Anyone?
Here's a recipe (though in a different context):

http://wiki.squeak.org/squeak/ObsoleteClasses

- Bert -
Hilaire Fernandes
2012-01-28 12:16:30 UTC
Permalink
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
Post by 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
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
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
http://lists.laptop.org/listinfo/etoys
--
http://blog.ofset.org/hilaire
Smalltalkers do: [:it | All with: Class, (And love: it)]
Ties Stuij
2012-01-28 12:16:30 UTC
Permalink
Post by Hilaire Fernandes
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?
Post by Hilaire Fernandes
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,

/Ties
Andreas Raab
2012-01-28 12:16:30 UTC
Permalink
Post by Ties Stuij
Post by Hilaire Fernandes
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.
Post by Ties Stuij
Post by Hilaire Fernandes
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
Hilaire Fernandes
2012-01-28 12:16:31 UTC
Permalink
Post by Andreas Raab
Post by Ties Stuij
Post by Hilaire Fernandes
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.
To be accurate, what happen if one drag and drop a jpeg file in an
image, then save a project file, move the project in another computer
without the original jpeg file? Is the jpeg file saved in the .pr zip
file as well?

As a concrete simple example, how can I examine the content of this
project file http://swiki.ofset.org:8000/super/36 (produced with a 3.8
image)?

It use 3 graphics and I am really curious to know what inside the .pr file.

The info I got from the .pr is:
***@tice:/tmp$ file ENGRENAGE4.001.pr
ENGRENAGE4.001.pr: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)

Once gunzipped, I can't examine the content...

Hilaire
--
http://blog.ofset.org/hilaire
Smalltalkers do: [:it | All with: Class, (And love: it)]
Hans-Martin Mosner
2012-01-28 12:16:31 UTC
Permalink
Post by Hilaire Fernandes
As a concrete simple example, how can I examine the content of this
project file http://swiki.ofset.org:8000/super/36 (produced with a 3.8
image)?
It use 3 graphics and I am really curious to know what inside the .pr file.
ENGRENAGE4.001.pr: gzip compressed data, from FAT filesystem (MS-DOS, OS/2, NT)
Once gunzipped, I can't examine the content...
Probably the file command is confused about this file.
.pr files are just ZIP files, so you should be able to unzip the file to
see its contents.

Cheers,
Hans-Martin
Bert Freudenberg
2012-01-28 12:16:31 UTC
Permalink
Post by Hans-Martin Mosner
Post by Hilaire Fernandes
As a concrete simple example, how can I examine the content of this
project file http://swiki.ofset.org:8000/super/36 (produced with a 3.8
image)?
It use 3 graphics and I am really curious to know what inside
the .pr file.
ENGRENAGE4.001.pr: gzip compressed data, from FAT filesystem (MS-
DOS, OS/2, NT)
Once gunzipped, I can't examine the content...
Probably the file command is confused about this file.
.pr files are just ZIP files, so you should be able to unzip the file to
see its contents.
The format for .pr files changed over time.

Hilaire's ENGRENAGE4.001.pr is indeed just a gzip-compressed object
file, after decompressing it begins thus:

'From Squeak3.8 of ''5 May 2005'' [latest update: #6665] on 26
September 2005 at 4:44:57 pm'!
!ObjectScanner new initialize!
!self smartRefStream!

... followed by the data.

Newer .pr files are zipped, and contain yet another .pr file which is
a raw image segment.

And then there is the new project file format that we are switching to
now, it's a high-level text-based project description rather than a
direct object serialization.

The project loading code is pretty flexible and accepts many
combinations of plain/zipped/gzipped refstreams or image segments or s-
expressions.

- Bert -
Bert Freudenberg
2012-01-28 12:16:31 UTC
Permalink
Post by Hilaire Fernandes
As a concrete simple example, how can I examine the content of this
project file http://swiki.ofset.org:8000/super/36 (produced with a 3.8
image)?
It use 3 graphics and I am really curious to know what inside
the .pr file.
ENGRENAGE4.001.pr: gzip compressed data, from FAT filesystem (MS-
DOS, OS/2, NT)
Once gunzipped, I can't examine the content...
Why not? After gunzipping, you can inspect what is in it:

(FileStream readOnlyFileNamed:'ENGRENAGE4.001') fileInObjectAndCode

You get an ImageSegment containing 9195 objects with 250 outpointers.
The objects have these classes:

(arrayOfRoots collect: [:each | each class]) asBag sortedCounts

a SortedCollection(1176->Point 1146->Association 1121->Array 908-
Post by Hilaire Fernandes
Rectangle 589->MorphExtension 555->Color 519->IdentityDictionary 434-
Bitmap 342->TableLayout 342->TableLayoutProperties 328->Float 326-
ByteString 167->SimpleBorder 141->Morph 139->ImageMorph 134-
StringMorph 90->EventHandler 78->TileMorph 72->TilePadMorph 51-
AlignmentMorph 42->PhraseTileMorph 39->SketchMorph 38-
OrderedCollection 36->IconicButton 33->UpdatingStringMorph 32-
CompiledMethod 24->SimpleButtonMorph 21->AssignmentTileMorph 18-
DiskProxy 17->WeakArray 13->StepMessage 12->ScriptEditorMorph 12-
ScriptInstantiation 12->TickIndicatorMorph 12->LinedTTCFont 12-
UpdatingSimpleButtonMorph 12->UpdatingThreePhaseButtonMorph 12-
UniclassScript 12->ScriptStatusControl 11->ScriptActivationButton 9-
SlotInformation 9->ByteArray 6->Form 5->TTCFont 4->TranslucentColor
4->ShortPointArray 4->ActorState 4->TTGlyph 4->PasteUpMorph 3-
Post by Hilaire Fernandes
MorphicTransform 3->Metaclass 3->MethodDictionary 3->ColorForm 3-
TransformationMorph 3->ScriptNameTile 3->ColorArray 3-
ClassOrganizer 3->ThumbnailMorph 3->NumericReadoutTile 3-
ViewerFlapTab 3->LayoutProperties 3->WatcherWrapper 2->MethodContext
2->Heap 2->Dictionary 2->DamageRecorder 2->HandMorph 2->BlockContext 1-
Post by Hilaire Fernandes
Player78 1->LocaleID 1->Player79 class 1->ChangeSet 1->Player78
class 1->MouseEvent 1->WorldState 1->TranscriptStream 1->Project 1-
Post by Hilaire Fernandes
Set 1->UnscriptedPlayer 1->LargePositiveInteger 1->Player77 class 1-
Player77 1->MacRomanInputInterpreter 1->Presenter 1->Player79)
Or you could have a look which forms are in the segment:

arrayOfRoots select: [:each | each isKindOf: Form]

#(Form(197x132x16) ColorForm(443x444x8) ColorForm(152x152x8)
Form(287x287x16) ColorForm(287x287x8) Form(152x152x16) Form(9x11x16)
Form(443x444x16) Form(9x11x16))

These appear to be your 3 gears as originally imported (the 8-bit
forms) plus the same but with a painted dot on top (the 16-bit forms).

And so on.

- Bert -
Yoshiki Ohshima
2012-01-28 12:16:34 UTC
Permalink
Hilaire,
Post by Hilaire Fernandes
To be accurate, what happen if one drag and drop a jpeg file in an
image, then save a project file, move the project in another computer
without the original jpeg file? Is the jpeg file saved in the .pr zip
file as well?
Currently, it forgets the original format and all are treated as the
same Form.

I contemplated that we can keep the original format, and if it was
JPEG, we could even keep the original bytes of JPEG data. The catch
is that if the user painted on the Sketch created from JPEG,
determining whether to make sense to store the result in JPEG or not
is not trivial.

-- Yoshiki
Hilaire Fernandes
2012-01-28 12:16:39 UTC
Permalink
Post by Yoshiki Ohshima
Hilaire,
Post by Hilaire Fernandes
To be accurate, what happen if one drag and drop a jpeg file in an
image, then save a project file, move the project in another computer
without the original jpeg file? Is the jpeg file saved in the .pr zip
file as well?
Currently, it forgets the original format and all are treated as the
same Form.
So we have clearly an issue there !
Post by Yoshiki Ohshima
I contemplated that we can keep the original format, and if it was
JPEG, we could even keep the original bytes of JPEG data. The catch
is that if the user painted on the Sketch created from JPEG,
determining whether to make sense to store the result in JPEG or not
is not trivial.
Indeed not trivial. A simple first helpful boost will that unmodified
image (JPEG, PNG, GIF) to be kept in original format.
It is very likely other users of Squeak will complain about that
problem (pr. file getting big pretty quickly).

Hilaire
--
http://blog.ofset.org/hilaire
Smalltalkers do: [:it | All with: Class, (And love: it)]
Bert Freudenberg
2012-01-28 12:16:31 UTC
Permalink
Post by Andreas Raab
Post by Ties Stuij
Post by Hilaire Fernandes
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.
I'm almost sure (though not 100%) that this code is not active
anymore, forms are nowadays alway stored as plain objects. It's easy
to test though - make a project, load a jpeg, save the project, unzip
it - there would have to be a jpeg in the zip.
Post by Andreas Raab
Post by Ties Stuij
Post by Hilaire Fernandes
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.
Actually, Yoshiki's new s-expression based project format does pretty
much exactly that.

- Bert -
Andreas Raab
2012-01-28 12:16:31 UTC
Permalink
Post by Andreas Raab
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.
I'm almost sure (though not 100%) that this code is not active anymore,
forms are nowadays alway stored as plain objects. It's easy to test
though - make a project, load a jpeg, save the project, unzip it - there
would have to be a jpeg in the zip.
Oops. Shows how up to date I am on this code base ;-)
Post by Andreas Raab
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.
Actually, Yoshiki's new s-expression based project format does pretty
much exactly that.
Yes, but I would still not recommend anyone start such a project until
they really understand what they're getting themselves into ;-)

Cheers,
- Andreas
Bert Freudenberg
2012-01-28 12:16:31 UTC
Permalink
On Wed, Mar 26, 2008 at 12:43 AM, Hilaire Fernandes
Post by Hilaire Fernandes
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?
As far as I know the forms are hibernated (that is, the form's Bitmap
in run-length encoded into a ByteArray) and stored as-is in the image
segment that then is zipped. Depending on the picture contents this
compresses quite well.

- Bert -
karl
2012-01-28 12:16:30 UTC
Permalink
Post by 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
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.
Post by Ties Stuij
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
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
Post by Ties Stuij
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
Ties Stuij
2012-01-28 12:16:30 UTC
Permalink
Post by karl
Sounds like you are onto something. There are some dark corners in the
project saving and loading classes and it needs some tlc.
Could you elaborate on this?

/Ties
karl
2012-01-28 12:16:30 UTC
Permalink
Post by Ties Stuij
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.
You have to load this fix to get the SoundLibraryTool access to file
compression:
https://dev.laptop.org/attachment/ticket/5353/SoundLibraryCompress.10.cs

Select the sound in the tool, bring up the halo menu and compress it
with gsm, ogg or speex codec

Karl
Ties Stuij
2012-01-28 12:16:30 UTC
Permalink
Post by karl
You have to load this fix to get the SoundLibraryTool access to file
https://dev.laptop.org/attachment/ticket/5353/SoundLibraryCompress.10.cs
Select the sound in the tool, bring up the halo menu and compress it
with gsm, ogg or speex codec
Karl
Thanks!

/Ties
Yoshiki Ohshima
2012-01-28 12:16:34 UTC
Permalink
Post by karl
Post by Ties Stuij
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.
You have to load this fix to get the SoundLibraryTool access to file
https://dev.laptop.org/attachment/ticket/5353/SoundLibraryCompress.10.cs
Select the sound in the tool, bring up the halo menu and compress it
with gsm, ogg or speex codec
Sorry, I wasn't following the ticket closely. This seems to be good
for inclusion. Also, you can choose the compression when recording
from the sound recorder.

-- Yoshiki
Bert Freudenberg
2012-01-28 12:16:31 UTC
Permalink
Post by Ties Stuij
So my question on this topic is: is there an argument for
retaining the double zipping?
Don't think so.
Post by Ties Stuij
And would there be a general need for a
'just save an uncompressed .pr file, instead of a bundle'
option/patch?
Possibly. Changesets welcome :)
Post by Ties Stuij
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
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.
Well, you also have to invoke the garbage collector (it will not kick
in if there is loads of memory still usable). And the OSX utility
cannot tell which memory is actually used. Look at the VM statistics
(in the help menu).
Post by Ties Stuij
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).
You need to find out what's holding onto the project, break that
reference, then the garbage collector will do its job.
Post by Ties Stuij
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?
Certainly - though image stripping is an art that tends to become
forgotten with todays gigabyte memory equipped machines.

You should start by looking at what is making your image larger than
expected - SpaceTally>>printSpaceAnalysis might help.

- Bert -
karl
2012-01-28 12:16:31 UTC
Permalink
Post by Bert Freudenberg
Post by Ties Stuij
So my question on this topic is: is there an argument for
retaining the double zipping?
Don't think so.
But some internal compression could help.

Here is two test cases:

I made a test project with and added 255k jpeg image to it and saved it.
The project was 1.6M.

I made another test project and added a 1.7M aiff file and compressed
the file with ogg. The saved project was 86k.

Could compressing the forms inside the image like we compress sounds help ?

Karl
Yoshiki Ohshima
2012-01-28 12:16:42 UTC
Permalink
Hello,

I published a few changes in last a couple of weeks; I just looked
at some inefficiency and avoid them.

I compared the project loading time in Etoys 2.3 (before Luke's method
dictionary patch) and Etoys 3.0 #1957. I loaded all projects in the
ExampleEtoys like this:

-------------------
| dir entries proj |
dir _ FileDirectory on: '/usr/share/etoys/ExampleEtoys'.
entries _ FileList2 projectOnlySelectionMethod: dir entries.
entries _ entries collect: [:each | Project parseProjectFileName: each first].
entries do: [:each |
Transcript show: '\classic: ' withCRs , each first, ' ', ([ProjectLoading loadFromDir: '/usr/share/etoys/ExampleEtoys' projectName: each first] timeToRun) printString.
proj _ (Project named: each first).
proj ifNotNil: [proj okToChangeSilently].
].
-------------------

got result (numbers are in milliseconds and are the average of three
runs):

BallDropAnalysis1 13850.3 9971 1.38906
BetterMovieUI 9662.67 6145 1.57244
BouncingBallAnimation 4825.33 3151.67 1.53104
CarAndPen 5676.33 3504.67 1.61965
ComputerLogicGame 14902.7 7080.33 2.1048
DemonCastle1 24442.7 11497.7 2.12588
EtoysChallenge 19955.7 10435.7 1.91226
FishAndPlankton 12526 9573.33 1.30843
FollowRoad 5532.33 3869.33 1.42979
JustPaintedCar 3777 2237 1.68842
LunarLanderGame 7730 5286.67 1.46217
MakeAMovie 8909.67 5718 1.55818
MiddleOfRoad 6056 3554 1.704
ParticlesDyeInWater 11483.3 5672.33 2.02445
ParticlesEpidemic 9368.67 5116.33 1.83113
ParticlesGasModel 10688 4668.67 2.2893
RandomRacing 7013.33 4263.33 1.64504
SalmonSniff 5943 3912.33 1.51904
SimpleSprings 5563 4566.67 1.21818
SpeedAcceleration 6150.67 4421.33 1.39113
StartOfDTPDocument 4577.67 3090.67 1.48113
SteeringTheCar 6285.67 4388.67 1.43225
TurtleGeometry 6117.67 3903.33 1.56729
Welcome 22904 11830.3 1.93604

I haven't done anything about the double compression problem,
putting media file aside, nor looking at the saving side. But now
project loading is 20%-100% faster than before, and bigger projects
seem to benefit more.

I have been experimenting another new format in S-expression, but
found that for bigger projects, the new format is much slower. Unless
there is a way to optimize it, or some other reason, probably we stick
with the old format for now...

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

-- Yoshiki
karl
2012-01-28 12:16:44 UTC
Permalink
Post by Yoshiki Ohshima
Hello,
I published a few changes in last a couple of weeks; I just looked
at some inefficiency and avoid them.
I compared the project loading time in Etoys 2.3 (before Luke's method
dictionary patch) and Etoys 3.0 #1957. I loaded all projects in the
-------------------
| dir entries proj |
dir _ FileDirectory on: '/usr/share/etoys/ExampleEtoys'.
entries _ FileList2 projectOnlySelectionMethod: dir entries.
entries _ entries collect: [:each | Project parseProjectFileName: each first].
entries do: [:each |
Transcript show: '\classic: ' withCRs , each first, ' ', ([ProjectLoading loadFromDir: '/usr/share/etoys/ExampleEtoys' projectName: each first] timeToRun) printString.
proj _ (Project named: each first).
proj ifNotNil: [proj okToChangeSilently].
].
-------------------
got result (numbers are in milliseconds and are the average of three
BallDropAnalysis1 13850.3 9971 1.38906
BetterMovieUI 9662.67 6145 1.57244
BouncingBallAnimation 4825.33 3151.67 1.53104
CarAndPen 5676.33 3504.67 1.61965
ComputerLogicGame 14902.7 7080.33 2.1048
DemonCastle1 24442.7 11497.7 2.12588
EtoysChallenge 19955.7 10435.7 1.91226
FishAndPlankton 12526 9573.33 1.30843
FollowRoad 5532.33 3869.33 1.42979
JustPaintedCar 3777 2237 1.68842
LunarLanderGame 7730 5286.67 1.46217
MakeAMovie 8909.67 5718 1.55818
MiddleOfRoad 6056 3554 1.704
ParticlesDyeInWater 11483.3 5672.33 2.02445
ParticlesEpidemic 9368.67 5116.33 1.83113
ParticlesGasModel 10688 4668.67 2.2893
RandomRacing 7013.33 4263.33 1.64504
SalmonSniff 5943 3912.33 1.51904
SimpleSprings 5563 4566.67 1.21818
SpeedAcceleration 6150.67 4421.33 1.39113
StartOfDTPDocument 4577.67 3090.67 1.48113
SteeringTheCar 6285.67 4388.67 1.43225
TurtleGeometry 6117.67 3903.33 1.56729
Welcome 22904 11830.3 1.93604
I haven't done anything about the double compression problem,
putting media file aside, nor looking at the saving side. But now
project loading is 20%-100% faster than before, and bigger projects
seem to benefit more.
Great progress. Do the big project contain lots of forms ? Sound is very
efficiently compressed instances with the ogg plugin and maybe something
similar would be possible for forms.

Karl
Post by Yoshiki Ohshima
I have been experimenting another new format in S-expression, but
found that for bigger projects, the new format is much slower. Unless
there is a way to optimize it, or some other reason, probably we stick
with the old format for now...
I'll try to modify the code so that .pr file may not have to be
compressed and see if how much we gain.
-- Yoshiki
_______________________________________________
Etoys mailing list
http://lists.laptop.org/listinfo/etoys
Ties Stuij
2012-01-28 12:16:46 UTC
Permalink
Post by Yoshiki Ohshima
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.squeakfoundation.org/pipermail/squeak-dev/attachments/20080407/cdce977b/fileInfix.1.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.squeakfoundation.org/pipermail/squeak-dev/attachments/20080407/cdce977b/asUnzippedStream.1.obj
Yoshiki Ohshima
2012-01-28 12:16:58 UTC
Permalink
Hi, Ties,
Post by Ties Stuij
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.
Hmm. What was the performance impact by this?
Post by Ties Stuij
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.
One time, we thought that we would rather give a feedback while
something is going on... 25 seconds with some visible progress going
on vs. 20 seconds with frozen screen and it is still debatable whether
which would be better.

However, is it true that this progress may not be relevant much as
other part of project loading will spend more time?

-- Yoshiki
John M McIntosh
2012-01-28 12:16:58 UTC
Permalink
Post by Yoshiki Ohshima
One time, we thought that we would rather give a feedback while
something is going on... 25 seconds with some visible progress going
on vs. 20 seconds with frozen screen and it is still debatable whether
which would be better.
I've seen this handled by poping up the visible progress screen, but
only if say
5 or 10 seconds have gone by. So for fast operations you are not
impacted by
the drawing, but longer operations then get the progress screen.
Post by Yoshiki Ohshima
However, is it true that this progress may not be relevant much as
other part of project loading will spend more time?
-- Yoshiki
--
=
=
=
========================================================================
John M. McIntosh <***@smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
Ties Stuij
2012-01-28 12:16:58 UTC
Permalink
Post by Yoshiki Ohshima
Hi, Ties,
Post by Ties Stuij
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.
Hmm. What was the performance impact by this?
None, but when an uncompressed .pr file sits in another archive, the
code that makes a stream for the .pr file makes the wrong kind of
stream for said .pr file. So it's a simple bugfix.

/Ties
Yoshiki Ohshima
2012-01-28 12:17:00 UTC
Permalink
Post by Ties Stuij
Post by Yoshiki Ohshima
Post by Ties Stuij
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.
Hmm. What was the performance impact by this?
None, but when an uncompressed .pr file sits in another archive, the
code that makes a stream for the .pr file makes the wrong kind of
stream for said .pr file. So it's a simple bugfix.
But, this does make the current project loading slower to me. Try
(in an updated image):

MessageTally spyOn: [ProjectLoading loadFromDir:
'/usr/share/etoys/ExampleEtoys' projectName: 'DemonCastle1'].

or such with and without the change and see the result.

But, yes, I agree that there seems to be some potential "hanging
fruit" here. Thank you for attacking this!

-- Yoshiki
Ties Stuij
2012-01-28 12:16:59 UTC
Permalink
Post by Yoshiki Ohshima
One time, we thought that we would rather give a feedback while
something is going on... 25 seconds with some visible progress going
on vs. 20 seconds with frozen screen and it is still debatable whether
which would be better.
You mean that no info whatsoever is given when unzipping? I didn't pay
much attention to the project progress bar, but I did notice that with
big projects it takes a while to show so I presumed it was unzipping.
I thought we could just as well start showing the progress bar before
we start zipping. An empty progress bar is information enough I would
think, and the rest of the filling of the progress bar is hardwired,
after certain operations, so the bar is already incrementing in steps
(five or something I thought).
Post by Yoshiki Ohshima
However, is it true that this progress may not be relevant much as
other part of project loading will spend more time?
You definitely notice it on the XO with 1mb+ files.

/Ties
Post by Yoshiki Ohshima
-- Yoshiki
Yoshiki Ohshima
2012-01-28 12:17:00 UTC
Permalink
Post by Ties Stuij
Post by Yoshiki Ohshima
However, is it true that this progress may not be relevant much as
other part of project loading will spend more time?
You definitely notice it on the XO with 1mb+ files.
Yes. Takashi reminded me that the #upToEndProgressBar in
ReadWriteStream was when we were showing stacked progress bars. Now
we only show one bar (that goes back and forth), it makes perfect
sense to apply your patch.

Thank you!

-- Yoshiki

Continue reading on narkive:
Loading...