marcus told me once that scriptloader was already getting a big class with a lot of method. For now I do not have something else than removing all tests and scriptloader. I removed a lot of bookMorph but still it is hanging there :)

Stef

On May 5, 2009, at 5:53 PM, John M McIntosh wrote:

...

No, the intent is preserve the images as they are shipped see

http://www.mobilewikiserver.com/ST80Docs.html & http://www.mobilewikiserver.com/SqueakDocs.html

However if you have a script that removals all the *extra* things that people could run for server images that would be helpful at least to me, I realize that most folks don't care about 8MB, but on tiny devices that 8MB is golden...

On 5-May-09, at 1:28 AM, stéphane ducasse wrote:

...

John

for your images did you remove tests and other unnecessary stuff? The 10300 is 12.7mb without removing all kind of crap like the scriptLoader and the tests. I hope that we will be able to slowly get more and more modular: once project/bookmorph are gone. I imagine (did not read carefully the details of we got about the chase of the unclosed handles) that the startup behavior could be also improved.

Stef

On May 5, 2009, at 10:17 AM, John M McIntosh wrote:

...

Tsk, well I was off to bed, but thought I should make some notes.

Last night I push out two electronic books showing smalltalk-80 based source code to Apple for iPhone review. One was based on the latest pharo of end of april 09 with closures the other based on the sq3.10.2-719web09.04.1.zip no closures. The two e-books apps are identical except for the code base.

I dropped the wikiserver stuff into both, happy since the changes required were non-existent for pharo and one or two for sq3.10.2

(a) The sq3.10.2 version was missing some of the extra add-on Pier stuff, and has the LGPL Swazoo which makes some folks run for the fire exit.

(b) The pharo image is 20.2 mb, the sq3.10.2 is 25.2 mb, so 5MB bigger.

(c) The pharo image needed about 35mb of ram to be happy, the sq 3.10.2 about 40mb (c2) The pharo image ramps to the welcome screen using 19.23 mb ram, 97.12mb virtual (c3) The sq 3.10.2 image ramps using 19.05mb and 102.12 virtual. This makes sense because I avoid a full gc and doing allInstances, so the code base is really startup logic and seaside. (I had to fix the sq 3.10.2 image because of ignored bug using allInstances I reported years back, never fixed, but fixed in pharo last fall).

(d) The pharo image needs 2.6 to 6.6% cpu on the iphone at idle, the sq 3.10.2 needs 8 to 18% (to be fair here I could bring some fixes into the 3.10.2 image to reduce the cpu time, but really those fixes should have gone in years ago...)

(e) The sq 3.10.2 book feels sluggish. the pharo less so. So the sq 3.10.2 excessive CPU usage is the usability killer here.

To be fair WikiServer is happy with 20MB of ram with a 10.5MB image size, and runs with a 0 to 0.9% cpu usage at idle, starup ram of 11.69, virtual memory of 90.34 Lots of hours to get there..

PS I see the etoys image is only 16.4 MB, well that doesn't include seaside etc, but if you need that you should start with etoys as the base and add pier and seaside, less bloated I'd guess, and supported for that etoy feature set you need?

= = = = = = ===================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = = = = =====================================================================