why are Bitmaps instanciated even in headless mode?
Locked
why are Bitmaps instanciated even in headless mode?
 
|
I took a dev image, and run them in two ways: the normal and headless. For each I did a:
"Smalltalk garbageCollect. SpaceTally new printSpaceAnalysis" Normal one: Class code space # instances inst space percent Bitmap 3753 133 11099904 37.4 ByteString 2515 85110 6106378 20.6 CompiledMethod 19130 59452 3703463 12.5 Array 2176 77579 2561928 8.6 ...... Headless: Class code space # instances inst space percent ByteString 2515 85110 6106378 24.7 Bitmap 3753 126 6049208 24.5 CompiledMethod 19130 59452 3703463 15.0 Array 2176 77577 2561844 10.4 ...... So....even in headless mode, I have 133 instances of Bitmap, representing 24.5% of the memory.... Ok, 24.5 is better than 37.5, but I don't understand why Bitmap instances are created. Why they are needed ? is there a way to garbageCollect them? thanks Mariano _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: why are Bitmaps instanciated even in headless mode?
|
|
Well, my 1.1 dev image has:
Class code space # instances inst space percent Bitmap 3753 8906 19427212 31.9 ByteString 2515 190202 17459895 28.6 Array 2176 137567 5198744 8.5 CompiledMethod 19130 79223 4888481 8.0 ByteSymbol 1062 52650 1330679 2.2 MethodDictionary 2135 9854 1302376 2.1 MCVersionInfo 1313 22841 913640 1.5 Association 710 74216 890592 1.5 Character 6355 66219 794628 1.3 DateAndTime 7893 28026 672624 1.1 ByteArray 3458 640 639048 1.0 While my 1.1. deploy image (incl Seaside 3 and Glorp) has: CompiledMethod 18784 53888 3082849 20.7 Bitmap 3753 184 2837256 19.0 ByteString 2515 47865 2713211 18.2 Array 2176 45399 2277268 15.3 ByteSymbol 1062 37522 925078 6.2 Character 6355 66219 794628 5.3 MethodDictionary 2135 6296 468456 3.1 WeakArray 718 127 324104 2.2 Association 710 23189 278268 1.9 ByteArray 3370 341 213357 1.4 ClassOrganizer 1326 6112 195584 1.3 Metaclass 3909 3078 123120 0.8 This reduction is done by ScriptLoader>>#cleanUpForRelease (after deleting all unit test packages). HTH, Sven On 24 Aug 2010, at 14:18, Mariano Martinez Peck wrote: I took a dev image, and run them in two ways: the normal and headless. For each I did a: _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: why are Bitmaps instanciated even in headless mode?
|
|
2010/8/24 Sven Van Caekenberghe <[hidden email]>
Thanks Sven. It seems my mail was not clear at all. I know that with #cleanUpForRelease it will reduce, but my question is....if I understand correlty what a Bitmap is, why they are nstantiated when I am running headless? shouldn't the amount of instances be 0? I think I don't understand what really the -headless does. I thought the world was not display, not Bitmap was instanciated, etc... cheers Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: why are Bitmaps instanciated even in headless mode?
|
|
Mariano,
On 24 Aug 2010, at 14:44, Mariano Martinez Peck wrote: > Thanks Sven. It seems my mail was not clear at all. I know that with #cleanUpForRelease it will reduce, but my question is....if I understand correlty what a Bitmap is, why they are nstantiated when I am running headless? shouldn't the amount of instances be 0? > > I think I don't understand what really the -headless does. I thought the world was not display, not Bitmap was instanciated, etc... OK, that is a different question, sorry. Isn't it so that these Bitmap instances are just regular Smalltalk objects that live the Smalltalk heap and that by definition all live Smalltalk objects get saved into the image file ? I don't think they are different from regular arrays. Running -headless (actually -vm-display-null -vm-sound-null) just instructs the VM to connect to a dummy (null) display and sound device, so that display operations have no effect, as far as I understand. Sven _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: why are Bitmaps instanciated even in headless mode?
|
|
In reply to this post by Mariano Martinez Peck
2010/8/24 Mariano Martinez Peck <[hidden email]>:
> > > 2010/8/24 Sven Van Caekenberghe <[hidden email]> >> >> Well, my 1.1 dev image has: >> Class code space # instances inst space percent >> Bitmap 3753 8906 19427212 >> 31.9 >> ByteString 2515 190202 17459895 >> 28.6 >> Array 2176 137567 5198744 >> 8.5 >> CompiledMethod 19130 79223 4888481 >> 8.0 >> ByteSymbol 1062 52650 1330679 >> 2.2 >> MethodDictionary 2135 9854 1302376 >> 2.1 >> MCVersionInfo 1313 22841 913640 >> 1.5 >> Association 710 74216 890592 >> 1.5 >> Character 6355 66219 794628 >> 1.3 >> DateAndTime 7893 28026 672624 >> 1.1 >> ByteArray 3458 640 639048 >> 1.0 >> While my 1.1. deploy image (incl Seaside 3 and Glorp) has: >> CompiledMethod 18784 53888 3082849 >> 20.7 >> Bitmap 3753 184 2837256 >> 19.0 >> ByteString 2515 47865 2713211 >> 18.2 >> Array 2176 45399 2277268 >> 15.3 >> ByteSymbol 1062 37522 925078 >> 6.2 >> Character 6355 66219 794628 >> 5.3 >> MethodDictionary 2135 6296 468456 >> 3.1 >> WeakArray 718 127 324104 >> 2.2 >> Association 710 23189 278268 >> 1.9 >> ByteArray 3370 341 213357 >> 1.4 >> ClassOrganizer 1326 6112 195584 >> 1.3 >> Metaclass 3909 3078 123120 >> 0.8 >> >> This reduction is done by ScriptLoader>>#cleanUpForRelease (after deleting >> all unit test packages). > > Thanks Sven. It seems my mail was not clear at all. I know that with > #cleanUpForRelease it will reduce, but my question is....if I understand > correlty what a Bitmap is, why they are nstantiated when I am running > headless? shouldn't the amount of instances be 0? > > I think I don't understand what really the -headless does. I thought the > world was not display, not Bitmap was instanciated, etc... > Sure, you can still draw on the display, bitblit things, create morphs, move windows around, query pixels, etc. Display is a global variable that doesn't just disappear. Otherwise things like RFB Server and the Seaside Screen wouldn't work. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: why are Bitmaps instanciated even in headless mode?
|
|
In reply to this post by Sven Van Caekenberghe
That makes complete sense, and it is a crushingly disappointing realization :( I'll get over it, but it is all the more reason to eventually strive for the Dolphin session-based model. Then deployed console apps would not have a GUI at all, for real. I will admit that there is something to be said for having something running headless and then magically popping into a GUI, locally or remotely, but something that is really headless, not merely making a bunch of calls that are artificially no-ops, has value too and we can't build that right now.
BTW, hopefully no one is thinking of making it impossible to create bitmaps when headless, right? That would be bad for web servers and other things that create graphics for use elsewhere. Sorry to even mention it, but... Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Sven Van Caekenberghe [[hidden email]] Sent: Tuesday, August 24, 2010 8:59 AM To: [hidden email] Subject: Re: [Pharo-project] why are Bitmaps instanciated even in headless mode? Running -headless (actually -vm-display-null -vm-sound-null) just instructs the VM to connect to a dummy (null) display and sound device, so that display operations have no effect, as far as I understand. Sven _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [SPAM] Re: why are Bitmaps instanciated even in headless mode?
|
|
It depends on how you look at it: a properly configured deployed seaside image will have zero windows and will never popup anything, so it makes no difference. I never use the RFB model, mostly out of principle, a server app should not have a classic gui. The seaside development tools allow you to upgrade MC packages, browse code, execute doits, save the image, kill processes, ...
That being said, the headless support in VW 7 is very nice (mainly capturing display activity into errors, errors/transcript go to stdout/stderr/logfile, options to make std image headless and vice versa). Sven On 25 Aug 2010, at 12:18, Schwab,Wilhelm K wrote: > That makes complete sense, and it is a crushingly disappointing realization :( I'll get over it, but it is all the more reason to eventually strive for the Dolphin session-based model. Then deployed console apps would not have a GUI at all, for real. I will admit that there is something to be said for having something running headless and then magically popping into a GUI, locally or remotely, but something that is really headless, not merely making a bunch of calls that are artificially no-ops, has value too and we can't build that right now. > > BTW, hopefully no one is thinking of making it impossible to create bitmaps when headless, right? That would be bad for web servers and other things that create graphics for use elsewhere. Sorry to even mention it, but... > > Bill > > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Sven Van Caekenberghe [[hidden email]] > Sent: Tuesday, August 24, 2010 8:59 AM > To: [hidden email] > Subject: Re: [Pharo-project] why are Bitmaps instanciated even in headless mode? > > > Running -headless (actually -vm-display-null -vm-sound-null) just instructs the VM to connect to a dummy (null) display and sound device, so that display operations have no effect, as far as I understand. > > Sven > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [SPAM] Re: why are Bitmaps instanciated even in headless mode?
|
|
On Aug 25, 2010, at 12:49 PM, Sven Van Caekenberghe wrote: > It depends on how you look at it: a properly configured deployed seaside image will have zero windows and will never popup anything, so it makes no difference. I never use the RFB model, mostly out of principle, a server app should not have a classic gui. The seaside development tools allow you to upgrade MC packages, browse code, execute doits, save the image, kill processes, ... > > That being said, the headless support in VW 7 is very nice (mainly capturing display activity into errors, errors/transcript go to stdout/stderr/logfile, options to make std image headless and vice versa). we should arrive one day to that :) > > Sven > > On 25 Aug 2010, at 12:18, Schwab,Wilhelm K wrote: > >> That makes complete sense, and it is a crushingly disappointing realization :( I'll get over it, but it is all the more reason to eventually strive for the Dolphin session-based model. Then deployed console apps would not have a GUI at all, for real. I will admit that there is something to be said for having something running headless and then magically popping into a GUI, locally or remotely, but something that is really headless, not merely making a bunch of calls that are artificially no-ops, has value too and we can't build that right now. >> >> BTW, hopefully no one is thinking of making it impossible to create bitmaps when headless, right? That would be bad for web servers and other things that create graphics for use elsewhere. Sorry to even mention it, but... >> >> Bill >> >> >> ________________________________________ >> From: [hidden email] [[hidden email]] On Behalf Of Sven Van Caekenberghe [[hidden email]] >> Sent: Tuesday, August 24, 2010 8:59 AM >> To: [hidden email] >> Subject: Re: [Pharo-project] why are Bitmaps instanciated even in headless mode? >> >> >> Running -headless (actually -vm-display-null -vm-sound-null) just instructs the VM to connect to a dummy (null) display and sound device, so that display operations have no effect, as far as I understand. >> >> Sven >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [SPAM] Re: why are Bitmaps instanciated even in headless mode?
|
|
Options are always good. I would not at all recommend removing the current null display and sound drivers. However, it would be nice to see the image and vm cooperate to emulate Dolphin's session managers and associated deployment design. IMHO Object Arts went a little overboard with stripping; we would not have to work that hard at it to have something very useful.
Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]] Sent: Wednesday, August 25, 2010 1:06 PM To: [hidden email] Subject: Re: [Pharo-project] [SPAM] Re: why are Bitmaps instanciated even in headless mode? On Aug 25, 2010, at 12:49 PM, Sven Van Caekenberghe wrote: > It depends on how you look at it: a properly configured deployed seaside image will have zero windows and will never popup anything, so it makes no difference. I never use the RFB model, mostly out of principle, a server app should not have a classic gui. The seaside development tools allow you to upgrade MC packages, browse code, execute doits, save the image, kill processes, ... > > That being said, the headless support in VW 7 is very nice (mainly capturing display activity into errors, errors/transcript go to stdout/stderr/logfile, options to make std image headless and vice versa). we should arrive one day to that :) > > Sven > > On 25 Aug 2010, at 12:18, Schwab,Wilhelm K wrote: > >> That makes complete sense, and it is a crushingly disappointing realization :( I'll get over it, but it is all the more reason to eventually strive for the Dolphin session-based model. Then deployed console apps would not have a GUI at all, for real. I will admit that there is something to be said for having something running headless and then magically popping into a GUI, locally or remotely, but something that is really headless, not merely making a bunch of calls that are artificially no-ops, has value too and we can't build that right now. >> >> BTW, hopefully no one is thinking of making it impossible to create bitmaps when headless, right? That would be bad for web servers and other things that create graphics for use elsewhere. Sorry to even mention it, but... >> >> Bill >> >> >> ________________________________________ >> From: [hidden email] [[hidden email]] On Behalf Of Sven Van Caekenberghe [[hidden email]] >> Sent: Tuesday, August 24, 2010 8:59 AM >> To: [hidden email] >> Subject: Re: [Pharo-project] why are Bitmaps instanciated even in headless mode? >> >> >> Running -headless (actually -vm-display-null -vm-sound-null) just instructs the VM to connect to a dummy (null) display and sound device, so that display operations have no effect, as far as I understand. >> >> Sven >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |