Wow! For the download of 40524, the image is 24.2, opening it and saving it gets that down to 23.2MB.This is more than 10MB smaller than a week ago. Other things TODO to make it even smaller: - Hunt down that one GTPlayground instance that is hanging around - fix class annitations to not allocate 4000 empty dictionaries: https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-propert... <https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-propert...> - why is the image smaller after saving it once? https://pharo.fogbugz.com/f/cases/14367/image-from-CI-grows-with-each-build-... <https://pharo.fogbugz.com/f/cases/14367/image-from-CI-grows-with-each-build-...> Marcus
On 02 Mar 2015, at 16:43, Marcus Denker <marcus.denker@inria.fr> wrote:
Wow!
For the download of 40524, the image is 24.2, opening it and saving it gets that down to 23.2MB.This is more than 10MB smaller than a week ago.
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around
this should be done, after I fixed the bug I introduced with the morph event processing :)
- fix class annitations to not allocate 4000 empty dictionaries: https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-propert... <https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-propert...> - why is the image smaller after saving it once? https://pharo.fogbugz.com/f/cases/14367/image-from-CI-grows-with-each-build-... <https://pharo.fogbugz.com/f/cases/14367/image-from-CI-grows-with-each-build-...>
Marcus
On 02 Mar 2015, at 16:47, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 02 Mar 2015, at 16:43, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Wow!
For the download of 40524, the image is 24.2, opening it and saving it gets that down to 23.2MB.This is more than 10MB smaller than a week ago.
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around
this should be done, after I fixed the bug I introduced with the morph event processing :)
No, sadly it still is there⦠Marcus
On 02 Mar 2015, at 16:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 02 Mar 2015, at 16:47, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 02 Mar 2015, at 16:43, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Wow!
For the download of 40524, the image is 24.2, opening it and saving it gets that down to 23.2MB.This is more than 10MB smaller than a week ago.
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around
this should be done, after I fixed the bug I introduced with the morph event processing :)
No, sadly it still is thereâ¦
ok⦠then is not my fault (and I have no idea what causes it) :)
Marcus
On 02 Mar 2015, at 16:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 02 Mar 2015, at 16:47, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 02 Mar 2015, at 16:43, Marcus Denker <marcus.denker@inria.fr> wrote:
Wow!
For the download of 40524, the image is 24.2, opening it and saving it gets that down to 23.2MB.This is more than 10MB smaller than a week ago.
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around
this should be done, after I fixed the bug I introduced with the morph event processing :)
No, sadly it still is thereâ¦
Marcus
Than we won't be able to include GTPlayground in the release ... ;-)
On 02 Mar 2015, at 16:58, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 02 Mar 2015, at 16:49, Marcus Denker <marcus.denker@inria.fr> wrote:
On 02 Mar 2015, at 16:47, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 02 Mar 2015, at 16:43, Marcus Denker <marcus.denker@inria.fr> wrote:
Wow!
For the download of 40524, the image is 24.2, opening it and saving it gets that down to 23.2MB.This is more than 10MB smaller than a week ago.
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around
this should be done, after I fixed the bug I introduced with the morph event processing :)
No, sadly it still is thereâ¦
Marcus
Than we won't be able to include GTPlayground in the release ... ;-)
But if you can remove it, the problem would be solved⦠Marcus
On Mon, Mar 2, 2015 at 4:47 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 02 Mar 2015, at 16:43, Marcus Denker <marcus.denker@inria.fr> wrote:
Wow!
For the download of 40524, the image is 24.2, opening it and saving it gets that down to 23.2MB.This is more than 10MB smaller than a week ago.
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around
this should be done, after I fixed the bug I introduced with the morph event processing :)
Aha! So it was you :) Could you describe the issue? Doru
- fix class annitations to not allocate 4000 empty dictionaries:
https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-propert... - why is the image smaller after saving it once?
https://pharo.fogbugz.com/f/cases/14367/image-from-CI-grows-with-each-build-...
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
On 02 Mar 2015, at 16:43, Marcus Denker <marcus.denker@inria.fr> wrote:
Wow!
For the download of 40524, the image is 24.2, opening it and saving it gets that down to 23.2MB.This is more than 10MB smaller than a week ago.
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around - fix class annitations to not allocate 4000 empty dictionaries: https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-propert... - why is the image smaller after saving it once? https://pharo.fogbugz.com/f/cases/14367/image-from-CI-grows-with-each-build-...
Marcus
Yes, this is very cool progress. I love it that so many small things are happening everywhere and that they reinforce each other. And then sometimes, something has a lot of effect ;-) We have to make the build green too, as we are progressing to a release. Sven
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around - fix class annitations to not allocate 4000 empty dictionaries: https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-propert... <https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-propert...>
I submitted a fix. Marcus
On 02 Mar 2015, at 18:29, Marcus Denker <marcus.denker@inria.fr> wrote:
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around
This is *strange*. I was able to get it down to 1 Smalltalk garbageCollect. Smalltalk garbageCollect. Smalltalk garbageCollect. GTPlayground allInstances size. and then I saved that and uploaded it the build server. Now all the Undeclareds are gone. Yet, when I download the last build, open *one* GTPlayground: GTPlayground allInstances size ==> 2. There is something happening that I donât understand.
- fix class annitations to not allocate 4000 empty dictionaries: https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-propert... <https://pharo.fogbugz.com/f/cases/14956/Properties-on-Behaviour-self-propert...> Integrated.
Size: 22.9MB (== 21.8 MiB, people obsessed with memory size tend to think binary). Marcus
Size: 22.9MB (== 21.8 MiB, people obsessed with memory size tend to think binary).
Another ~150KB savings for review: https://pharo.fogbugz.com/f/cases/15032/ScriptLoader-does-not-need-to-log-th... <https://pharo.fogbugz.com/f/cases/15032/ScriptLoader-does-not-need-to-log-th...> Scriptloader has an old mechanism to log all descriptions of updates. These days the discription is a) always just a lost of issue tracker issues b) available in the Monticello history of the ScriptLoader package. ==> the slice removes the ~160Kb String from the image. Marcus
On 03 Mar 2015, at 10:20, Marcus Denker <marcus.denker@inria.fr> wrote:
Size: 22.9MB (== 21.8 MiB, people obsessed with memory size tend to think binary).
Another ~150KB savings for review:
https://pharo.fogbugz.com/f/cases/15032/ScriptLoader-does-not-need-to-log-th... <https://pharo.fogbugz.com/f/cases/15032/ScriptLoader-does-not-need-to-log-th...>
Scriptloader has an old mechanism to log all descriptions of updates. These days the discription is a) always just a lost of issue tracker issues b) available in the Monticello history of the ScriptLoader package.
==> the slice removes the ~160Kb String from the image.
Ok, this is now in and the image is now 22.7MB. with all examples, tests, tutorials, ConfigurationOf, Metacello... Marcus
Le 4 mars 2015 08:51, "Marcus Denker" <marcus.denker@inria.fr> a écrit :
On 03 Mar 2015, at 10:20, Marcus Denker <marcus.denker@inria.fr> wrote:
Size: 22.9MB (== 21.8 MiB, people obsessed with memory size tend to
think binary).
Another ~150KB savings for review:
https://pharo.fogbugz.com/f/cases/15032/ScriptLoader-does-not-need-to-log-th...
Scriptloader has an old mechanism to log all descriptions of updates.
These days the discription is
a) always just a lost of issue tracker issues b) available in the Monticello history of the ScriptLoader package.
==> the slice removes the ~160Kb String from the image.
Ok, this is now in and the image is now 22.7MB. with all examples, tests, tutorials, ConfigurationOf, Metacello...
Looks like we'll be able to start boasting about that... Phil
Marcus
Ok, this is now in and the image is now 22.7MB. with all examples,
tests, tutorials, ConfigurationOf,
Metacello...
Looks like we'll be able to start boasting about that...
It is a first step... There is still a lot of duplicated and dead code, for example. But aside from that:
We should really have a look into sharing e.g. identical large strings (using a copy-on-write proxy) and compression... e.g. Forms are compressed (see #hibernate) on shutdown. Why no do more like that, but more late bound? Most of the 22MB are not part of the working set... we could gain a lot of space by compressing once as the last state of the build. Another thing I would like to have is to compress the distribution images and have the VM uncompress them on startup. LZ4 decompresses with 2GB/second *per core*... and the resulting image would be 12MB. This way we could have .pharo images and just use those, no need to have a zip on the build server. Marcus
On Wed, Mar 4, 2015 at 1:56 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
Ok, this is now in and the image is now 22.7MB. with all examples, tests, tutorials, ConfigurationOf, Metacello...
Looks like we'll be able to start boasting about that...
It is a first step... There is still a lot of duplicated and dead code, for example. But aside from that:
We should really have a look into sharing e.g. identical large strings (using a copy-on-write proxy) and compression... e.g. Forms are compressed (see #hibernate) on shutdown. Why no do more like that, but more late bound? Most of the 22MB are not part of the working set... we could gain a lot of space by compressing once as the last state of the build.
Another thing I would like to have is to compress the distribution images and have the VM uncompress them on startup. LZ4 decompresses with 2GB/second *per core*... and the resulting image would be 12MB. This way we could have .pharo images and just use those, no need to have a zip on the build server.
Interesting but not sure I'd like to have images going through decompression everytime I spin them up. Especially if there are a lot of the in a server. Phil
Marcus
On 04 Mar 2015, at 14:19, phil@highoctane.be wrote:
On Wed, Mar 4, 2015 at 1:56 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
Ok, this is now in and the image is now 22.7MB. with all examples, tests, tutorials, ConfigurationOf, Metacello...
Looks like we'll be able to start boasting about that...
It is a first step... There is still a lot of duplicated and dead code, for example. But aside from that:
We should really have a look into sharing e.g. identical large strings (using a copy-on-write proxy) and compression... e.g. Forms are compressed (see #hibernate) on shutdown. Why no do more like that, but more late bound? Most of the 22MB are not part of the working set... we could gain a lot of space by compressing once as the last state of the build.
Another thing I would like to have is to compress the distribution images and have the VM uncompress them on startup. LZ4 decompresses with 2GB/second *per core*... and the resulting image would be 12MB. This way we could have .pharo images and just use those, no need to have a zip on the build server.
Interesting but not sure I'd like to have images going through decompression everytime I spin them up. Especially if there are a lot of the in a server
As I said: it decompresses with 2GB/second. How much slower would the startup be for a 22MB image? (The idea would be to only do that for small images) To quote https://code.google.com/p/lz4/ ââ¦. extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems." Marcus
Le 04/03/2015 14:29, Marcus Denker a écrit :
On 04 Mar 2015, at 14:19, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
On Wed, Mar 4, 2015 at 1:56 PM, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Ok, this is now in and the image is now 22.7MB. with all examples, tests, tutorials, ConfigurationOf, Metacello...
Looks like we'll be able to start boasting about that...
It is a first step... There is still a lot of duplicated and dead code, for example. But aside from that:
We should really have a look into sharing e.g. identical large strings (using a copy-on-write proxy) and compression... e.g. Forms are compressed (see #hibernate) on shutdown. Why no do more like that, but more late bound? Most of the 22MB are not part of the working set... we could gain a lot of space by compressing once as the last state of the build.
Another thing I would like to have is to compress the distribution images and have the VM uncompress them on startup. LZ4 decompresses with 2GB/second *per core*... and the resulting image would be 12MB. This way we could have .pharo images and just use those, no need to have a zip on the build server.
Interesting but not sure I'd like to have images going through decompression everytime I spin them up. Especially if there are a lot of the in a server
As I said: it decompresses with 2GB/second. How much slower would the startup be for a 22MB image? (The idea would be to only do that for small images)
To quote https://code.google.com/p/lz4/
ââ¦. extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems."
Marcus
Are you sure it's worth the added complexity of a self-decoding image in lz4 (as well as a dependency on yet one more external item)? Thierry
As I said: it decompresses with 2GB/second. How much slower would the startup be for a 22MB image? (The idea would be to only do that for small images)
To quote https://code.google.com/p/lz4/
ââ¦. extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems."
Marcus
Are you sure it's worth the added complexity of a self-decoding image in lz4 (as well as a dependency on yet one more external item)?
LZ4 makes sense in general even for other things⦠(in image use for compression) and it is tiny. Marcus
Am 04.03.2015 um 14:19 schrieb phil@highoctane.be:
On Wed, Mar 4, 2015 at 1:56 PM, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Ok, this is now in and the image is now 22.7MB. with all examples, tests, tutorials, ConfigurationOf, Metacello...
Looks like we'll be able to start boasting about that...
It is a first step... There is still a lot of duplicated and dead code, for example. But aside from that:
We should really have a look into sharing e.g. identical large strings (using a copy-on-write proxy) and compression... e.g. Forms are compressed (see #hibernate) on shutdown. Why no do more like that, but more late bound? Most of the 22MB are not part of the working set... we could gain a lot of space by compressing once as the last state of the build.
Another thing I would like to have is to compress the distribution images and have the VM uncompress them on startup. LZ4 decompresses with 2GB/second *per core*... and the resulting image would be 12MB. This way we could have .pharo images and just use those, no need to have a zip on the build server.
Interesting but not sure I'd like to have images going through decompression everytime I spin them up. Especially if there are a lot of the in a server.
To be sure if you want that you have to test it. You have always take into account that a smaller file will have less I/O to read from disk. This could lead into a speed up because you spare slow disk I/O and compensate with fast memory operations. Even if there isn't a benefit you are always free to decompress the image and put it on disk. No need to use it like it was delivered. And btw. how often do you need to spin up a server?? ;) Norbert
On 04/03/15 14:19, phil@highoctane.be wrote:
Interesting but not sure I'd like to have images going through decompression everytime I spin them up. Especially if there are a lot of the in a server.
2GB/s is twice as fast as you can get from a fast SSD atm. And as that is per core, that puts a boundary of starting 2200 pharo images/s on a modern dual socket server. After half a minute of that you run out of ram with a 1.5TB ram machine. The bottlenecks might be elsewhere. Norbert wrote:
To be sure if you want that you have to test it. You have always take into account that a smaller file will have less I/O to read from disk.
+1 Stephan
Le 4 mars 2015 23:08, "Stephan Eggermont" <stephan@stack.nl> a écrit :
On 04/03/15 14:19, phil@highoctane.be wrote:
Interesting but not sure I'd like to have images going through decompression everytime I spin them up. Especially if there are a lot of the in a server.
2GB/s is twice as fast as you can get from a fast SSD atm. And as that is per core, that puts a boundary of starting 2200 pharo images/s on a modern dual socket server. After half a minute of that you run out of ram with a 1.5TB ram machine. The bottlenecks might be elsewhere.
There is no way an image starts that fast today. There is the delay thing that slows things down.
Norbert wrote:
To be sure if you want that you have to test it. You have always take >
into account that a smaller file will have less I/O to read from disk.
+1
Ok.
Stephan
On Thu, Mar 5, 2015 at 2:08 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Le 4 mars 2015 23:08, "Stephan Eggermont" <stephan@stack.nl> a écrit :
On 04/03/15 14:19, phil@highoctane.be wrote:
Interesting but not sure I'd like to have images going through decompression everytime I spin them up. Especially if there are a lot of the in a server.
2GB/s is twice as fast as you can get from a fast SSD atm. And as that is per core, that puts a boundary of starting 2200 pharo images/s on a modern dual socket server. After half a minute of that you run out of ram with a 1.5TB ram machine. The bottlenecks might be elsewhere.
There is no way an image starts that fast today.
There is the delay thing that slows things down.
Is this the code Eliot advised would not be needed when we've moved to the microsecond clock? Can you point me at the code? cheers -ben
Norbert wrote:
To be sure if you want that you have to test it. You have always take into account that a smaller file will have less I/O to read from disk.
+1
Ok.
Stephan
On Thu, Mar 5, 2015 at 10:55 AM, Ben Coman <btc@openinworld.com> wrote:
On Thu, Mar 5, 2015 at 2:08 PM, phil@highoctane.be <phil@highoctane.be> wrote:
Le 4 mars 2015 23:08, "Stephan Eggermont" <stephan@stack.nl> a écrit :
On 04/03/15 14:19, phil@highoctane.be wrote:
Interesting but not sure I'd like to have images going through decompression everytime I spin them up. Especially if there are a lot of the in a server.
2GB/s is twice as fast as you can get from a fast SSD atm. And as that is per core, that puts a boundary of starting 2200 pharo images/s on a modern dual socket server. After half a minute of that you run out of ram with a 1.5TB ram machine. The bottlenecks might be elsewhere.
There is no way an image starts that fast today.
There is the delay thing that slows things down.
Is this the code Eliot advised would not be needed when we've moved to the microsecond clock? Can you point me at the code? cheers -ben
Hi ben I've been following your Delay related work (sorry for the lack of feedback, still, I read it all). I will review where these things are and send you what I do find. t Images are starting slow, that's my experience. Here, a Pharo3 on Windows with quite a bunch of things in it takes six seconds to load on first launch and three after that. And that's on a i7 4770K clocked 3.85GHz with SSD drives. It takes less time to revive a VMWare VM :-( Phil
Norbert wrote:
To be sure if you want that you have to test it. You have always take
into account that a smaller file will have less I/O to read from disk.
+1
Ok.
Stephan
Phil,
On 05 Mar 2015, at 11:44, phil@highoctane.be wrote:
Images are starting slow, that's my experience. Here, a Pharo3 on Windows with quite a bunch of things in it takes six seconds to load on first launch and three after that.
And that's on a i7 4770K clocked 3.85GHz with SSD drives.
It takes less time to revive a VMWare VM :-(
Maybe it is Windows ? Or certain extra stuff that you have in your image that does work at startup ? Because you should see sub second startup times. (This is on the smallest Digital Ocean instance, 1 virtual CPU, 512 Mb RAM, SSD) root@stfx:~/experiments/pharo4# curl get.pharo.org/40+vm | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2885 100 2885 0 0 17974 0 --:--:-- --:--:-- --:--:-- 18031 Downloading the latest 40 Image: http://files.pharo.org/image/40/latest.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/vm/pharo/linux/stable.zip pharo-vm/pharo Downloading PharoV10.sources: http://files.pharo.org/sources//PharoV10.sources.zip Downloading PharoV20.sources: http://files.pharo.org/sources//PharoV20.sources.zip Downloading PharoV30.sources: http://files.pharo.org/sources//PharoV30.sources.zip Creating starter scripts pharo and pharo-ui root@stfx:~/experiments/pharo4# ./pharo Pharo.image printVersion [version] 4.0 #40535 root@stfx:~/experiments/pharo4# ls -lah Pharo.image -rw-rw-r-- 1 root root 22M Mar 4 14:51 Pharo.image root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 real 0m0.386s user 0m0.184s sys 0m0.028s root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 real 0m0.422s user 0m0.192s sys 0m0.032s root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 real 0m0.863s user 0m0.404s sys 0m0.064s It is the latest (smaller) image, but that should not make much difference. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
On Thu, Mar 5, 2015 at 12:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Phil,
On 05 Mar 2015, at 11:44, phil@highoctane.be wrote:
Images are starting slow, that's my experience. Here, a Pharo3 on Windows with quite a bunch of things in it takes six seconds to load on first launch and three after that.
And that's on a i7 4770K clocked 3.85GHz with SSD drives.
It takes less time to revive a VMWare VM :-(
Maybe it is Windows ? Or certain extra stuff that you have in your image that does work at startup ? Because you should see sub second startup times.
(This is on the smallest Digital Ocean instance, 1 virtual CPU, 512 Mb RAM, SSD)
root@stfx:~/experiments/pharo4# curl get.pharo.org/40+vm | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2885 100 2885 0 0 17974 0 --:--:-- --:--:-- --:--:-- 18031 Downloading the latest 40 Image: http://files.pharo.org/image/40/latest.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/vm/pharo/linux/stable.zip pharo-vm/pharo Downloading PharoV10.sources: http://files.pharo.org/sources//PharoV10.sources.zip Downloading PharoV20.sources: http://files.pharo.org/sources//PharoV20.sources.zip Downloading PharoV30.sources: http://files.pharo.org/sources//PharoV30.sources.zip Creating starter scripts pharo and pharo-ui
root@stfx:~/experiments/pharo4# ./pharo Pharo.image printVersion [version] 4.0 #40535
root@stfx:~/experiments/pharo4# ls -lah Pharo.image -rw-rw-r-- 1 root root 22M Mar 4 14:51 Pharo.image
root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
real 0m0.386s user 0m0.184s sys 0m0.028s
root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
real 0m0.422s user 0m0.192s sys 0m0.032s
root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
real 0m0.863s user 0m0.404s sys 0m0.064s
It is the latest (smaller) image, but that should not make much difference.
On my CentOS Linux, headless tests are fast as well. Granted, my Windows image was super large. 300Megs or something. I cleaned the Monticello things with flush cache, which removed 41 megs. I can't test the CLI version on Windows, as I do get a window opening. There are a ton of windows and morphs open in there and I've run a couple of experiments. Now, the Linux image was large too. 200Megs or so. And the window showed immediately, then it took a second and a half or so to show the images back. There is a black background before. Maybe the system is processing its startUp list, unhibernating forms, I don't know what's going on but it takes that 1.5 secs. The image gets large because of Monticello caches, and TWM (Tiling Window Manager) keeping a handle on browsers etc over time. So, I cleaned the caches, closed TWM, gc'ed a time or two and then got the image back to 90 megs. Then the image opens in like 0.5 sec. It is hard to measure as what I want is the time between issuing the pharo-ui XYZ.image and the fact that I can actually see the UI. How would one do that? Sorry for the rant but generally speaking, the Pharo UI seems slower than the Squeak 4.5 ui. Or the EToys UI for that matter. I am using those for little educational programs and they feel faster. I'd like to know why. Both systems have morphic. Is it because of aliased fonts? Squeak 4.5 also has that. Is there any way to monitor what's going on during image startup? Phil
Sven
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
On Thu, Mar 5, 2015 at 4:45 AM, phil@highoctane.be <phil@highoctane.be> wrote:
On Thu, Mar 5, 2015 at 12:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Phil,
On 05 Mar 2015, at 11:44, phil@highoctane.be wrote:
Images are starting slow, that's my experience. Here, a Pharo3 on Windows with quite a bunch of things in it takes six seconds to load on first launch and three after that.
And that's on a i7 4770K clocked 3.85GHz with SSD drives.
It takes less time to revive a VMWare VM :-(
Maybe it is Windows ? Or certain extra stuff that you have in your image that does work at startup ? Because you should see sub second startup times.
(This is on the smallest Digital Ocean instance, 1 virtual CPU, 512 Mb RAM, SSD)
root@stfx:~/experiments/pharo4# curl get.pharo.org/40+vm | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2885 100 2885 0 0 17974 0 --:--:-- --:--:-- --:--:-- 18031 Downloading the latest 40 Image: http://files.pharo.org/image/40/latest.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/vm/pharo/linux/stable.zip pharo-vm/pharo Downloading PharoV10.sources: http://files.pharo.org/sources//PharoV10.sources.zip Downloading PharoV20.sources: http://files.pharo.org/sources//PharoV20.sources.zip Downloading PharoV30.sources: http://files.pharo.org/sources//PharoV30.sources.zip Creating starter scripts pharo and pharo-ui
root@stfx:~/experiments/pharo4# ./pharo Pharo.image printVersion [version] 4.0 #40535
root@stfx:~/experiments/pharo4# ls -lah Pharo.image -rw-rw-r-- 1 root root 22M Mar 4 14:51 Pharo.image
root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial'
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
real 0m0.386s user 0m0.184s sys 0m0.028s
root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100
factorial'
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
real 0m0.422s user 0m0.192s sys 0m0.032s
root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100
factorial'
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
real 0m0.863s user 0m0.404s sys 0m0.064s
It is the latest (smaller) image, but that should not make much
difference.
On my CentOS Linux, headless tests are fast as well.
Granted, my Windows image was super large. 300Megs or something. I cleaned the Monticello things with flush cache, which removed 41 megs.
I can't test the CLI version on Windows, as I do get a window opening.
There are a ton of windows and morphs open in there and I've run a couple of experiments.
Now, the Linux image was large too. 200Megs or so. And the window showed immediately, then it took a second and a half or so to show the images back. There is a black background before. Maybe the system is processing its startUp list, unhibernating forms, I don't know what's going on but it takes that 1.5 secs.
The image gets large because of Monticello caches, and TWM (Tiling Window Manager) keeping a handle on browsers etc over time. So, I cleaned the caches, closed TWM, gc'ed a time or two and then got the image back to 90 megs.
Then the image opens in like 0.5 sec. It is hard to measure as what I want is the time between issuing the pharo-ui XYZ.image and the fact that I can actually see the UI.
How would one do that?
Sorry for the rant but generally speaking, the Pharo UI seems slower than the Squeak 4.5 ui. Or the EToys UI for that matter. I am using those for little educational programs and they feel faster. I'd like to know why. Both systems have morphic. Is it because of aliased fonts? Squeak 4.5 also has that.
Is there any way to monitor what's going on during image startup?
I modifier the AndreasSystemProfiler in the Squeak code base at Cadence to allow profiling across snapshot; you see both save and startup profiles. That's not showing e.g. disc activity from VM reads, but it does help track down tike spent in the SMalltalk start-up. IIRC this is in te Saueak code base. But if you're interested I can dig it out. The changes are minor; to do with correctly offsetting delays across snapshot.
Phil
Sven
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
-- best, Eliot
Le 5 mars 2015 22:54, "Eliot Miranda" <eliot.miranda@gmail.com> a écrit :
On Thu, Mar 5, 2015 at 4:45 AM, phil@highoctane.be <phil@highoctane.be>
wrote:
On Thu, Mar 5, 2015 at 12:05 PM, Sven Van Caekenberghe <sven@stfx.eu>
wrote:
Phil,
On 05 Mar 2015, at 11:44, phil@highoctane.be wrote:
Images are starting slow, that's my experience. Here, a Pharo3 on Windows with quite a bunch of things in it takes six seconds to load on first launch and three after that.
And that's on a i7 4770K clocked 3.85GHz with SSD drives.
It takes less time to revive a VMWare VM :-(
Maybe it is Windows ? Or certain extra stuff that you have in your image that does work at startup ? Because you should see sub second startup times.
(This is on the smallest Digital Ocean instance, 1 virtual CPU, 512 Mb RAM, SSD)
root@stfx:~/experiments/pharo4# curl get.pharo.org/40+vm | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 2885 100 2885 0 0 17974 0 --:--:-- --:--:-- --:--:-- 18031 Downloading the latest 40 Image: http://files.pharo.org/image/40/latest.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/vm/pharo/linux/stable.zip pharo-vm/pharo Downloading PharoV10.sources: http://files.pharo.org/sources//PharoV10.sources.zip Downloading PharoV20.sources: http://files.pharo.org/sources//PharoV20.sources.zip Downloading PharoV30.sources: http://files.pharo.org/sources//PharoV30.sources.zip Creating starter scripts pharo and pharo-ui
root@stfx:~/experiments/pharo4# ./pharo Pharo.image printVersion [version] 4.0 #40535
root@stfx:~/experiments/pharo4# ls -lah Pharo.image -rw-rw-r-- 1 root root 22M Mar 4 14:51 Pharo.image
root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial'
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
real 0m0.386s user 0m0.184s sys 0m0.028s
root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100
factorial'
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
real 0m0.422s user 0m0.192s sys 0m0.032s
root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100
factorial'
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
real 0m0.863s user 0m0.404s sys 0m0.064s
It is the latest (smaller) image, but that should not make much
difference.
On my CentOS Linux, headless tests are fast as well.
Granted, my Windows image was super large. 300Megs or something. I cleaned the Monticello things with flush cache, which removed 41 megs.
I can't test the CLI version on Windows, as I do get a window opening.
There are a ton of windows and morphs open in there and I've run a couple of experiments.
Now, the Linux image was large too. 200Megs or so. And the window showed immediately, then it took a second and a half or so to show the images back. There is a black background before. Maybe the system is processing its startUp list, unhibernating forms, I don't know what's going on but it takes that 1.5 secs.
The image gets large because of Monticello caches, and TWM (Tiling Window Manager) keeping a handle on browsers etc over time. So, I cleaned the caches, closed TWM, gc'ed a time or two and then got the image back to 90 megs.
Then the image opens in like 0.5 sec. It is hard to measure as what I want is the time between issuing the pharo-ui XYZ.image and the fact that I can actually see the UI.
How would one do that?
Sorry for the rant but generally speaking, the Pharo UI seems slower than the Squeak 4.5 ui. Or the EToys UI for that matter. I am using those for little educational programs and they feel faster. I'd like to know why. Both systems have morphic. Is it because of aliased fonts? Squeak 4.5 also has that.
Is there any way to monitor what's going on during image startup?
I modifier the AndreasSystemProfiler in the Squeak code base at Cadence to allow profiling across snapshot; you see both save and startup profiles. That's not showing e.g. disc activity from VM reads, but it does help track down tike spent in the SMalltalk start-up. IIRC this is in te Saueak code base. But if you're interested I can dig it out. The changes are minor; to do with correctly offsetting delays across snapshot.
Definitely! Phil
Phil
Sven
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
-- best, Eliot
Hi eliot It is a cool extension I would really like to get startup more exposed. Stef Le 5/3/15 22:53, Eliot Miranda a écrit :
On Thu, Mar 5, 2015 at 4:45 AM, phil@highoctane.be <mailto:phil@highoctane.be> <phil@highoctane.be <mailto:phil@highoctane.be>> wrote:
On Thu, Mar 5, 2015 at 12:05 PM, Sven Van Caekenberghe <sven@stfx.eu <mailto:sven@stfx.eu>> wrote: > Phil, > >> On 05 Mar 2015, at 11:44, phil@highoctane.be <mailto:phil@highoctane.be> wrote: >> >> Images are starting slow, that's my experience. Here, a Pharo3 on >> Windows with quite a bunch of things in it takes six seconds to load >> on first launch and three after that. >> >> And that's on a i7 4770K clocked 3.85GHz with SSD drives. >> >> It takes less time to revive a VMWare VM :-( > > Maybe it is Windows ? Or certain extra stuff that you have in your image that does work at startup ? Because you should see sub second startup times. > > (This is on the smallest Digital Ocean instance, 1 virtual CPU, 512 Mb RAM, SSD) > > root@stfx:~/experiments/pharo4# curl get.pharo.org/40+vm <http://get.pharo.org/40+vm> | bash > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 2885 100 2885 0 0 17974 0 --:--:-- --:--:-- --:--:-- 18031 > Downloading the latest 40 Image: > http://files.pharo.org/image/40/latest.zip > Pharo.image > Downloading the latest pharoVM: > http://files.pharo.org/vm/pharo/linux/stable.zip > pharo-vm/pharo > Downloading PharoV10.sources: > http://files.pharo.org/sources//PharoV10.sources.zip > Downloading PharoV20.sources: > http://files.pharo.org/sources//PharoV20.sources.zip > Downloading PharoV30.sources: > http://files.pharo.org/sources//PharoV30.sources.zip > Creating starter scripts pharo and pharo-ui > > root@stfx:~/experiments/pharo4# ./pharo Pharo.image printVersion > [version] 4.0 #40535 > > root@stfx:~/experiments/pharo4# ls -lah Pharo.image > -rw-rw-r-- 1 root root 22M Mar 4 14:51 Pharo.image > > root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' > 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 > > real 0m0.386s > user 0m0.184s > sys 0m0.028s > > root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' > 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 > > real 0m0.422s > user 0m0.192s > sys 0m0.032s > > root@stfx:~/experiments/pharo4# time ./pharo Pharo.image eval '100 factorial' > 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000 > > real 0m0.863s > user 0m0.404s > sys 0m0.064s > > It is the latest (smaller) image, but that should not make much difference.
On my CentOS Linux, headless tests are fast as well.
Granted, my Windows image was super large. 300Megs or something. I cleaned the Monticello things with flush cache, which removed 41 megs.
I can't test the CLI version on Windows, as I do get a window opening.
There are a ton of windows and morphs open in there and I've run a couple of experiments.
Now, the Linux image was large too. 200Megs or so. And the window showed immediately, then it took a second and a half or so to show the images back. There is a black background before. Maybe the system is processing its startUp list, unhibernating forms, I don't know what's going on but it takes that 1.5 secs.
The image gets large because of Monticello caches, and TWM (Tiling Window Manager) keeping a handle on browsers etc over time. So, I cleaned the caches, closed TWM, gc'ed a time or two and then got the image back to 90 megs.
Then the image opens in like 0.5 sec. It is hard to measure as what I want is the time between issuing the pharo-ui XYZ.image and the fact that I can actually see the UI.
How would one do that?
Sorry for the rant but generally speaking, the Pharo UI seems slower than the Squeak 4.5 ui. Or the EToys UI for that matter. I am using those for little educational programs and they feel faster. I'd like to know why. Both systems have morphic. Is it because of aliased fonts? Squeak 4.5 also has that.
Is there any way to monitor what's going on during image startup?
I modifier the AndreasSystemProfiler in the Squeak code base at Cadence to allow profiling across snapshot; you see both save and startup profiles. That's not showing e.g. disc activity from VM reads, but it does help track down tike spent in the SMalltalk start-up. IIRC this is in te Saueak code base. But if you're interested I can dig it out. The changes are minor; to do with correctly offsetting delays across snapshot.
Phil
> > Sven > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > >
-- best, Eliot
On 03 Mar 2015, at 08:06, Marcus Denker <marcus.denker@inria.fr> wrote:
On 02 Mar 2015, at 18:29, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around
This is *strange*. I was able to get it down to 1
Smalltalk garbageCollect. Smalltalk garbageCollect. Smalltalk garbageCollect. GTPlayground allInstances size.
and then I saved that and uploaded it the build server. Now all the Undeclareds are gone. Yet, when I download the last build, open *one* GTPlayground:
GTPlayground allInstances size ==> 2. There is something happening that I donât understand.
I think we found it: https://pharo.fogbugz.com/f/cases/15044/GTSpotterGlobalShortcut-class-needs-... Marcus
2015-03-03 15:14 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 03 Mar 2015, at 08:06, Marcus Denker <marcus.denker@inria.fr> wrote:
On 02 Mar 2015, at 18:29, Marcus Denker <marcus.denker@inria.fr> wrote:
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around
This is *strange*. I was able to get it down to 1
Smalltalk garbageCollect. Smalltalk garbageCollect. Smalltalk garbageCollect. GTPlayground allInstances size.
and then I saved that and uploaded it the build server. Now all the Undeclareds are gone. Yet, when I download the last build, open *one* GTPlayground:
GTPlayground allInstances size ==> 2. There is something happening that I donât understand.
I think we found it:
https://pharo.fogbugz.com/f/cases/15044/GTSpotterGlobalShortcut-class-needs-...
Marcus
Maybe there is another cause: "A fresh image that only uses old Workspace" Smalltalk garbageCollect. GTPlayground allInstances size. -> 1 (RubFindReplaceService classVarNamed:#Singleton) whenDialogDeleted. RubFindReplaceService classVarNamed:#Singleton put:nil Smalltalk garbageCollect. GTPlayground allInstances size. -> 0 RubFindReplaceService may nead a cleanUp, too. The whenDialogDeleted is called on a MorphDeleted announcement, but somehow this does not work, the method is never called, maybe the MorphDeleted is never announced?
On 03 Mar 2015, at 15:30, Nicolai Hess <nicolaihess@web.de> wrote:
2015-03-03 15:14 GMT+01:00 Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>>:
On 03 Mar 2015, at 08:06, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 02 Mar 2015, at 18:29, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around
This is *strange*. I was able to get it down to 1
Smalltalk garbageCollect. Smalltalk garbageCollect. Smalltalk garbageCollect. GTPlayground allInstances size.
and then I saved that and uploaded it the build server. Now all the Undeclareds are gone. Yet, when I download the last build, open *one* GTPlayground:
GTPlayground allInstances size ==> 2. There is something happening that I donât understand.
I think we found it:
https://pharo.fogbugz.com/f/cases/15044/GTSpotterGlobalShortcut-class-needs-... <https://pharo.fogbugz.com/f/cases/15044/GTSpotterGlobalShortcut-class-needs-...> Marcus
Maybe there is another cause:
"A fresh image that only uses old Workspace"
Smalltalk garbageCollect. GTPlayground allInstances size. -> 1
(RubFindReplaceService classVarNamed:#Singleton) whenDialogDeleted. RubFindReplaceService classVarNamed:#Singleton put:nil
Smalltalk garbageCollect. GTPlayground allInstances size. -> 0
RubFindReplaceService may nead a cleanUp, too.
Yes, all Singletons should be cleared on #cleanUp
The whenDialogDeleted is called on a MorphDeleted announcement, but somehow this does not work, the method is never called, maybe the MorphDeleted is never announced?
Could be, yes. Marcus
On Tue, Mar 3, 2015 at 3:30 PM, Nicolai Hess <nicolaihess@web.de> wrote:
2015-03-03 15:14 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:
On 03 Mar 2015, at 08:06, Marcus Denker <marcus.denker@inria.fr> wrote:
On 02 Mar 2015, at 18:29, Marcus Denker <marcus.denker@inria.fr> wrote:
Other things TODO to make it even smaller:
- Hunt down that one GTPlayground instance that is hanging around
This is *strange*. I was able to get it down to 1
Smalltalk garbageCollect. Smalltalk garbageCollect. Smalltalk garbageCollect. GTPlayground allInstances size.
and then I saved that and uploaded it the build server. Now all the Undeclareds are gone. Yet, when I download the last build, open *one* GTPlayground:
GTPlayground allInstances size ==> 2. There is something happening that I donât understand.
I think we found it:
https://pharo.fogbugz.com/f/cases/15044/GTSpotterGlobalShortcut-class-needs-...
Marcus
Maybe there is another cause:
"A fresh image that only uses old Workspace"
Smalltalk garbageCollect. GTPlayground allInstances size. -> 1
(RubFindReplaceService classVarNamed:#Singleton) whenDialogDeleted. RubFindReplaceService classVarNamed:#Singleton put:nil
Smalltalk garbageCollect. GTPlayground allInstances size. -> 0
Added a #cleanUp method to RubFindReplaceService Cheers, Andrei
RubFindReplaceService may nead a cleanUp, too. The whenDialogDeleted is called on a MorphDeleted announcement, but somehow this does not work, the method is never called, maybe the MorphDeleted is never announced?
participants (13)
-
Andrei Chis -
Ben Coman -
Eliot Miranda -
Esteban Lorenzano -
Marcus Denker -
Nicolai Hess -
Norbert Hartl -
phil＠highoctane.be -
Stephan Eggermont -
stepharo -
Sven Van Caekenberghe -
Thierry Goubier -
Tudor Girba