Re: [Pharo-users] Ever growing image
It will be great if somebody has images with this problem, and it can be shared without trouble, to share it. So we can investigate if the problem is image or vm related. On 1 Mar 2018 17:43, "Norbert Hartl" <norbert@hartl.name> wrote: I use 64bits on Mac and I suffer from this. Today I started a new image because the old one was 1,2 GB in size and starting to behave sluggish. Norbert
Am 01.03.2018 um 15:55 schrieb Hilaire <hilaire@drgeo.eu>:
Hi,
Does the current 64bits VM suffers of the ever growing image syndrom?
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
Sure, here is a DrGeo image of an unreasonnable size, you can investigage on: https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0 It is a based on a P7 64bits, don't use the shipped VMs, there are not matching. Thanks Hilaire Le 02/03/2018 à 09:13, tesonep@gmail.com a écrit :
It will be great if somebody has images with this problem, and it can be shared without trouble, to share it. So we can investigate if the problem is image or vm related.
-- Dr. Geo http://drgeo.eu
Thank you On 2 Mar 2018 09:23, "Hilaire" <hilaire@drgeo.eu> wrote:
Sure, here is a DrGeo image of an unreasonnable size, you can investigage on:
https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0
It is a based on a P7 64bits, don't use the shipped VMs, there are not matching.
Thanks
Hilaire
Le 02/03/2018 à 09:13, tesonep@gmail.com a écrit :
It will be great if somebody has images with this problem, and it can be shared without trouble, to share it. So we can investigate if the problem is image or vm related.
-- Dr. Geo http://drgeo.eu
Thanks Pablo! and Hilaire! On Fri, Mar 2, 2018 at 9:30 AM, tesonep@gmail.com <tesonep@gmail.com> wrote:
Thank you
On 2 Mar 2018 09:23, "Hilaire" <hilaire@drgeo.eu> wrote:
Sure, here is a DrGeo image of an unreasonnable size, you can investigage on:
https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0
It is a based on a P7 64bits, don't use the shipped VMs, there are not matching.
Thanks
Hilaire
Le 02/03/2018 à 09:13, tesonep@gmail.com a écrit :
It will be great if somebody has images with this problem, and it can be shared without trouble, to share it. So we can investigate if the problem is image or vm related.
-- Dr. Geo http://drgeo.eu
Hi Hilaire, is it possible that is the wrong image? This is a 32bits image, and it is around 52 MB, quite similar to the Pharo base image. Thanks. On Fri, Mar 2, 2018 at 11:27 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Thanks Pablo! and Hilaire!
On Fri, Mar 2, 2018 at 9:30 AM, tesonep@gmail.com <tesonep@gmail.com> wrote:
Thank you
On 2 Mar 2018 09:23, "Hilaire" <hilaire@drgeo.eu> wrote:
Sure, here is a DrGeo image of an unreasonnable size, you can
investigage
on:
https://www.dropbox.com/s/wc18e21p371z28f/DrGeo.app-18.01a.zip?dl=0
It is a based on a P7 64bits, don't use the shipped VMs, there are not matching.
Thanks
Hilaire
Le 02/03/2018 à 09:13, tesonep@gmail.com a écrit :
It will be great if somebody has images with this problem, and it can
be
shared without trouble, to share it. So we can investigate if the problem is image or vm related.
-- Dr. Geo http://drgeo.eu
-- Pablo Tesone. tesonep@gmail.com
Ah, you are right it is a 32bits image. My bad, Dr.Geo does not build with 64bits image Pharo7.0-64bit-52a28a8 ConfigurationOfDrGeo class methodsFor: 'metacelUnmatched ' in string literal. -> May be should try a more recent P7 64 bits image Note: 52 MB is an overlarge image size for me (down 50% will be nice) Hilaire Le 02/03/2018 à 16:41, tesonep@gmail.com a écrit :
Hi Hilaire, is it possible that is the wrong image? This is a 32bits image, and it is around 52 MB, quite similar to the Pharo base image.
-- Dr. Geo http://drgeo.eu
On 2 Mar 2018, at 21:31, Hilaire <hilaire@drgeo.eu> wrote:
Ah, you are right it is a 32bits image.
My bad, Dr.Geo does not build with 64bits image Pharo7.0-64bit-52a28a8
ConfigurationOfDrGeo class methodsFor: 'metacelUnmatched ' in string literal. ->
May be should try a more recent P7 64 bits image
Note: 52 MB is an overlarge image size for me (down 50% will be nice)
we should again do some analysis where space is going⦠the Pharo7 download is now 38MB (the image, decompressed). There are things to look for: 1) wasted space due to not thinking about memory and just âhaving itâ. Of course some of it are things like duplications (we now have 2 browsers, 2 inspectors, 2 debuggers⦠time to clean up a bitâ¦). Then every test we add takes space, every âhelp topicâ, every feature... But of course sometimes being able to invest memory into a better system can be important, too. Not all growth in memory is negativ if you can afford it. I always like to play the game to think âwhat would they have done in 1978 if they had this amount of memory in even a $5 machine?" Of course one can go very quickly in the wrong direction, but nevertheless: sometimes it is really worth to think about âspending memoryâ to buy abstraction. (especially a there are counter measures⦠we under-utilise both compression and disk storage) 2) wasted space that is just not needed. e.g. there is issue https://pharo.fogbugz.com/f/cases/21172/ <https://pharo.fogbugz.com/f/cases/21172/> That we have some huge strings to init unicode. Do we need them? 3) Memory leaks, bit they are more for the case when the system is running for a while. Marcus
Le 02/03/2018 à 22:52, Marcus Denker a écrit :
we should again do some analysis where space is going⦠the Pharo7 download is now 38MB (the image, decompressed).
Situation improved :) Remember P3 was just above 20 MB
There are things to look for:
1) wasted space due to not thinking about memory and just âhaving itâ.
Of course some of it are things like duplications (we now have 2 browsers, 2 inspectors, 2 debuggers⦠time to clean up a bitâ¦).
Then every test we add takes space, every âhelp topicâ, every feature...
It looks like this topic comes and goes since 20 years: new features added, image growth then/or it becomes hard to unload ; on Squeak then now with Pharo at a much higher rate. We all know about the right approach (GNU Smalltalk, CUIS Smalltalk), but it is not the road chosen with Pharo and it is becoming extremely uninteresting for me to code on DrGeo now. So far I fell ashame to ship end user application with a 50MB DrGeo image, knowing only 10% has purpose related to DrGeo domain. When situation improves, motivation may come back. For this same reason and other, I turned to Python for a planed programming course to mid high school students.
But of course sometimes being able to invest memory into a better system can be important, too. Not all growth in memory is negativ if you can afford it.
I always like to play the game to think âwhat would they have done in 1978 if they had this amount of memory in even a $5 machine?" Of course one can go very quickly in the wrong direction, but
Very likely not that much. May be the wonders came because of the hight constraints.
nevertheless: sometimes it is really worth to think about âspending memoryâ to buy abstraction. (especially a there are counter measures⦠we under-utilise both compression and disk storage) Helps could (should?) be file based, and maybe other stuff I don't know.
How the image is considered in the Pharo team? A kind of sacred place, where stuff are added following a few guidelines (you will not duplicate features but replace/imprive/whatever -- aka funny shortcut mess, you will make your code unloadable, etc...) or just like a forum where teams add feature according to projects or vision. Sorry to discuss these topics again, really don't want but still need to share a few thoughts.
2) wasted space that is just not needed. e.g. there is issue https://pharo.fogbugz.com/f/cases/21172/ Â Â That we have some huge strings to init unicode. Do we need them?
3) Memory leaks, bit they are more for the case when the system is running for a while.
-- Dr. Geo http://drgeo.eu
On a side note, being a long-time VW & VAST user, I've always felt the Image Stripper & Runtime Packager did a fairly good job at removing crap from the resulting image. I don't recall ready anything substantial comparing the Pharo way (bootstrapping from a minimal image and adding stuff) to the VW & VAST way (removing unreferenced stuff) but this would definitely be an interesting topic to read about. ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein) On Saturday, March 3, 2018, 9:22:06 AM EST, Hilaire <hilaire@drgeo.eu> wrote: Le 02/03/2018 à 22:52, Marcus Denker a écrit :
we should again do some analysis where space is going⦠the Pharo7 download is now 38MB (the image, decompressed).
Situation improved :) Remember P3 was just above 20 MB
Hi Hilaire,
On 3 Mar 2018, at 15:21, Hilaire <hilaire@drgeo.eu> wrote:
Le 02/03/2018 à 22:52, Marcus Denker a écrit :
we should again do some analysis where space is going⦠the Pharo7 download is now 38MB (the image, decompressed).
Situation improved :) Remember P3 was just above 20 MB
There are things to look for:
1) wasted space due to not thinking about memory and just âhaving itâ.
Of course some of it are things like duplications (we now have 2 browsers, 2 inspectors, 2 debuggers⦠time to clean up a bitâ¦).
Then every test we add takes space, every âhelp topicâ, every feature...
It looks like this topic comes and goes since 20 years: new features added, image growth then/or it becomes hard to unload ; on Squeak then now with Pharo at a much higher rate.
We all know about the right approach (GNU Smalltalk, CUIS Smalltalk), but it is not the road chosen with Pharo and it is becoming extremely uninteresting for me to code on DrGeo now. So far I fell ashame to ship end user application with a 50MB DrGeo image, knowing only 10% has purpose related to DrGeo domain. When situation improves, motivation may come back. For this same reason and other, I turned to Python for a planed programming course to mid high school students.
I think thatâs unfair. First, 38m is a really small application nowadays. I think for the amount of features included, 38m is a very small size (just look at any other application around⦠and of course scripting does not count by itself, it has to be added with all support files it come). Second, âthe right approachâ is always a matter of opinion. Of course, we believe *we* took the right path :) Third, yes, we added new functionality that could or could not be there (for example, I believe Athens should be a loadable project, not part of the image, but since everybody want to use it and even we were planning to move our tools to use, we included it). And yes, we have duplicated tools that we need to clean. But creating an environment that allow the development of any kind of application will always mean we increase the size of the release artefact. Finally fourth, we invested a LOT of effort on bootstrapping so you can do your image of the size you want. So yes, we deliver an image of 38m, and also a minimal image of 18m which you can use as base to create your production images. And if thatâs not enough, you can always do *your own*, since the scripts for doing it are available by just cloning the sources.
But of course sometimes being able to invest memory into a better system can be important, too. Not all growth in memory is negativ if you can afford it.
I always like to play the game to think âwhat would they have done in 1978 if they had this amount of memory in even a $5 machine?" Of course one can go very quickly in the wrong direction, but
Very likely not that much. May be the wonders came because of the hight constraints.
nevertheless: sometimes it is really worth to think about âspending memoryâ to buy abstraction. (especially a there are counter measures⦠we under-utilise both compression and disk storage) Helps could (should?) be file based, and maybe other stuff I don't know.
many things could be outside the image, yes. But then we need to distribute them. And that adds complexity.
How the image is considered in the Pharo team? A kind of sacred place, where stuff are added following a few guidelines (you will not duplicate features but replace/imprive/whatever -- aka funny shortcut mess, you will make your code unloadable, etc...) or just like a forum where teams add feature according to projects or vision.
We have a close control of what goes inside the image. And we take care things are well documented and with coherence of their components. Of course, we have made mistakes (maybe a lot), but in general things are improving. Esteban
Sorry to discuss these topics again, really don't want but still need to share a few thoughts.
2) wasted space that is just not needed. e.g. there is issue https://pharo.fogbugz.com/f/cases/21172/ That we have some huge strings to init unicode. Do we need them?
3) Memory leaks, bit they are more for the case when the system is running for a while.
-- Dr. Geo http://drgeo.eu
Hilaire It is up to you to give a real try. 1) Did you look for REAL at our infrastructure? Because you can take the bootstrapped image and change our build scripts. It took us may years to produce the loading scripts and this is the future. In Pharo 7 we have the possibility to have a core and several images. 2) Now I see you complaining but you can also help we never rejected a fix that make the system more modular. And we worked a lot to make it modular and IT IS MUCH MORE MODULAR. Now we do not have the energy to invest in building different image based on the core. So if you that need to not do it then why should we? 3) We will start a new reduction of the bootstrap core with Carolina PhD and you see we will not keep it for us (while we could). We want to have Pharo running on IoT devices. 4) We are starting to remove duplicated tools: Nautilus will go out, EyeInspector too. Old text model and widgets. Now again I personnally do not really care if Pharo has one or two mb more. 5) even on my old iPhone 53 mb is not that large. But I want a much smaller core and we will get there. 6) You see we introduce Athens in particular for Moose and DrGeo. Personnally I do not use at all Athens-Cairo. So this is funny how people react. Stef On Sat, Mar 3, 2018 at 3:21 PM, Hilaire <hilaire@drgeo.eu> wrote:
Le 02/03/2018 à 22:52, Marcus Denker a écrit :
we should again do some analysis where space is going⦠the Pharo7 download is now 38MB (the image, decompressed).
Situation improved :) Remember P3 was just above 20 MB
There are things to look for:
1) wasted space due to not thinking about memory and just âhaving itâ.
Of course some of it are things like duplications (we now have 2 browsers, 2 inspectors, 2 debuggers⦠time to clean up a bitâ¦).
Then every test we add takes space, every âhelp topicâ, every feature...
It looks like this topic comes and goes since 20 years: new features added, image growth then/or it becomes hard to unload ; on Squeak then now with Pharo at a much higher rate.
We all know about the right approach (GNU Smalltalk, CUIS Smalltalk), but it is not the road chosen with Pharo and it is becoming extremely uninteresting for me to code on DrGeo now. So far I fell ashame to ship end user application with a 50MB DrGeo image, knowing only 10% has purpose related to DrGeo domain. When situation improves, motivation may come back. For this same reason and other, I turned to Python for a planed programming course to mid high school students.
But of course sometimes being able to invest memory into a better system can be important, too. Not all growth in memory is negativ if you can afford it.
I always like to play the game to think âwhat would they have done in 1978 if they had this amount of memory in even a $5 machine?" Of course one can go very quickly in the wrong direction, but
Very likely not that much. May be the wonders came because of the hight constraints.
nevertheless: sometimes it is really worth to think about âspending memoryâ to buy abstraction. (especially a there are counter measures⦠we under-utilise both compression and disk storage)
Helps could (should?) be file based, and maybe other stuff I don't know.
How the image is considered in the Pharo team? A kind of sacred place, where stuff are added following a few guidelines (you will not duplicate features but replace/imprive/whatever -- aka funny shortcut mess, you will make your code unloadable, etc...) or just like a forum where teams add feature according to projects or vision.
Sorry to discuss these topics again, really don't want but still need to share a few thoughts.
2) wasted space that is just not needed. e.g. there is issue https://pharo.fogbugz.com/f/cases/21172/ That we have some huge strings to init unicode. Do we need them?
3) Memory leaks, bit they are more for the case when the system is running for a while.
-- Dr. Geo http://drgeo.eu
It looks like this topic comes and goes since 20 years: new features added, image growth then/or it becomes hard to unload ; on Squeak then now with Pharo at a much higher rate.
We all know about the right approach (GNU Smalltalk, CUIS Smalltalk),
I will not comment on that and suggest you to code with such systems. but it
is not the road chosen with Pharo and it is becoming extremely uninteresting for me to code on DrGeo now.
Fair. Do not do it.
So far I fell ashame to ship end user application with a 50MB DrGeo image, knowing only 10% has purpose related to DrGeo domain. When situation improves, motivation may come back. For this same reason and other, I turned to Python for a planed programming course to mid high school students.
Good luck. I was teaching python to my son and I have to explain to him that a set cannot contain a set or any object, that length is not a message and plenty of other nice things.
How the image is considered in the Pharo team? A kind of sacred place, where stuff are added following a few guidelines (you will not duplicate features but replace/imprive/whatever -- aka funny shortcut mess, you will make your code unloadable, etc...) or just like a forum where teams add feature according to projects or vision.
Hilaire if you believe that we are a bunch a morons this is up to you. Now we do pay a lot of attention to our system but our ressources are scarce and we try to satisfy many different concerns. And we do not get that much help from people. You see doing something real and of good quality takes a lot of time and energy. And I think that we are successful. It does not mean that we cannot improve.
Sorry to discuss these topics again, really don't want but still need to share a few thoughts.
I would prefer that you share some code and Pull Requests that always the same complains. But you can. Stef
On 2 Mar 2018, at 22:52, Marcus Denker <marcus.denker@inria.fr> wrote:
On 2 Mar 2018, at 21:31, Hilaire <hilaire@drgeo.eu <mailto:hilaire@drgeo.eu>> wrote:
Ah, you are right it is a 32bits image.
My bad, Dr.Geo does not build with 64bits image Pharo7.0-64bit-52a28a8
ConfigurationOfDrGeo class methodsFor: 'metacelUnmatched ' in string literal. ->
May be should try a more recent P7 64 bits image
Note: 52 MB is an overlarge image size for me (down 50% will be nice)
we should again do some analysis where space is going⦠the Pharo7 download is now 38MB (the image, decompressed).
down to 36,4 MB in the latest build. Marcus
Thanks Marcus! Le 09/03/2018 à 08:12, Marcus Denker a écrit :
we should again do some analysis where space is going⦠the Pharo7 download is now 38MB (the image, decompressed).
down to 36,4 MB in the latest build.
-- Dr. Geo http://drgeo.eu
participants (6)
-
Benoit St-Jean -
Esteban Lorenzano -
Hilaire -
Marcus Denker -
Stephane Ducasse -
tesonep＠gmail.com