- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Memory profiling

by Alexandre Bergel

Thanks Adrian and Henrik. I will check this... Cheers, Alexandre On 26 Apr 2011, at 08:21, Henrik Sperre Johansen wrote: > On 24.04.2011 05:32, Alexandre Bergel wrote: >> Hi! >> >> I have been working on a memory profiler for Pharo. People who attended Smalltalks'10 may remember Mariano Coca's presentation. >> >> Unfortunately, I am not satisfied with what we can obtain from the execution of a piece of code in Pharo. The amount of memory consumed by a method _significantly varies_ across execution. I have the impression that memory consumption is a less stable metric than execution time. >> >> For example, I used this as a benchmark: >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> 7 timesRepeat: [ >> 5 timesRepeat: [ Smalltalk garbageCollect]. >> MemoryProfiler >> viewProfiling: [ >> 20 timesRepeat: [| view | >> 5 timesRepeat: [ Smalltalk garbageCollect]. >> Object new. Object new. >> 5 timesRepeat: [ Smalltalk garbageCollect]. >> >> view := MOViewRenderer new. >> view nodes: (1 to: 5000). >> view root applyLayout] ] >> inPackagesMatching: 'Mondrian-*' >> ] >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> It opens a simple visualization in Mondrian. I tried to clean as much as I can before executing the code with multiple garbage collect. >> >> This piece of code return 7 profiles. >> In a profile I have for the method MOBoundedShape>>heightFor: : >> Number of Young Allocated Bytes: 42,879,008 bytes >> Number of Old Allocated Bytes: 6,000,660 bytes >> Total Allocated Bytes: 48,879,668 bytes >> Number of Increased Memory Bytes: 0 bytes >> Number of Incremental GC's: 1,415 >> Number of Full GC's: 0 >> Number of Tenures of Surving Objects: 164 >> >> In another profile I have: >> Number of Young Allocated Bytes: -7,857,156 bytes >> Number of Old Allocated Bytes: 6,008,872 bytes >> Total Allocated Bytes: -1,848,284 bytes >> Number of Increased Memory Bytes: 0 bytes >> Number of Incremental GC's: 1,373 >> Number of Full GC's: 0 >> Number of Tenures of Surving Objects: 165 >> >> In another: >> Number of Young Allocated Bytes: -11,956,720 bytes >> Number of Old Allocated Bytes: 5,315,216 bytes >> Total Allocated Bytes: -6,641,504 bytes >> Number of Increased Memory Bytes: 0 bytes >> Number of Incremental GC's: 1,354 >> Number of Full GC's: 0 >> Number of Tenures of Surving Objects: 145 >> >> And another: >> Number of Young Allocated Bytes: 59,132,472 bytes >> Number of Old Allocated Bytes: 6,177,772 bytes >> Total Allocated Bytes: 65,310,244 bytes >> Number of Increased Memory Bytes: 0 bytes >> Number of Incremental GC's: 1,361 >> Number of Full GC's: 0 >> Number of Tenures of Surving Objects: 167 >> >> The metric "Number of Young Allocated Bytes", "Number of Old Allocated Bytes", "Total Allocated Bytes" are highly unpredictable: i.e., two profiles are likely to be completely different. I am not sure why is this so. I use the standard Pharo1.2 One click, without additional parameter to the VM. Do you think that other platforms and languages behave the same? > It's not really surprising; since young space allocated size is shrunk by GC, a simple "value after block" - "value before block", for how much was actually allocated will give you rather random results. > > The amount of surviving objects (ie tenured into old allocated bytes)/tenures though is pretty much the same over the different runs, the differences can probably be explained by higher-priority process activity. > >> However, the positive point is that it seems that the amount of incremental GC and the number of tenured objects may play an important role in estimating the memory consumption. These metrics are much more stable. >> What do you think on this? Does it make sense to say that more a method triggers incremental GC, more it consumes memory? >> >> What exactly triggers an incremental GC? > http://wiki.squeak.org/squeak/1469 > "Eden collections are triggered by either running out of eden space, or allocating more than a certain number of objects (currently 4000) since the last collection " > Not sure if it's up to date, but I'd guess so. > > It's hard to build a Profiler for creation of non-transient objects during a run, since the creation and tenuring of created objects usually happens at entirely different places (around 200 incGC's per tenure in my image). > In other words, you can't really say that a method is "consuming" memory simply because a tenure happened during it's execution, and there was an increase in old space allocation, as some/many of the surviving objects could have been created 200 incGC's earlier. > > The amount of incGC's is usually a good indication of how many/how large objects are created during a methods execution though, due to the above mentioned trigger conditions. > In the context of determining overhead due to GC, those numbers are usually the interesting ones anyways. > > Cheers, > Henry > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 26, 2011

Re: [Pharo-project] Process for fixing a package in stable but not in core?

by StÃ©phane Ducasse

Hi michael this pharoseound settings is a mess. I probably contributed also because Beep beep was not working. I should take some time to really have a look. So far I a bit busy. we got some concurrent updates. The configurationOfSound if it exist should tell us which version to load. Or configurationOfPharo. In the future we will clean all that. Sorry for the problem. Stef On Apr 26, 2011, at 6:47 PM, Michael Forster wrote: > Hi, > > Forgive me, but I'm still new to the Pharo development process, and my > problem lies somewhere between being a Pharo developer and user. > > First, "Beeper beep" does not work in the current 1.2.1 image that I'm > using for production. I need to fix it and would like to share that > fix with the community. > > Second, I see from (closed) Issue 3489 that this is not a Pharo core > problem, but one with the PharoSound package, and that, apparently, it > might be fixed in the latest package version. > > Third, I fire up my 1.2.1 image, open the PharoSound squeaksource > repository in the monticello browser and discover that, as expected, > squeaksource does have some newer packages than the image. For > example, > > 1.2.1-image: Sound-GuillermoPolito.63 > > vs. > > squeaksource: Sound-MarianoMartinezPeck.65 > > > However, in other cases, the squeaksource package is _older_ than the > image's. For example, > > squeaksource: ConfigurationOfPharoSound-GuillermoPolito.17 > > vs. > > 1.2.1-image: ConfigurationOfPharoSound-GuillermoPolito.22. > > > How does one make sense of this? While can I reliably get the latest > version of PharoSound loaded in a 1.2.1 image so that I know I'm > writing and testing my fixes against a version that I can give back to > the community -- and, more importantly, won't be blown away by some > upcoming package version juggling? > > > Thanks, > > Mike >

April 26, 2011

Re: [Pharo-project] Do you want the option to copy a stacktrace to clipboard?

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 11:10 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > I support the idea. However, I am not sure I want this from the > PreDebugger. > > Yes, exactly. For the context menu I am sure I want it :) The question is in the pre debugger...and I am not quite sure... > Alexandre > > > > On 26 Apr 2011, at 15:59, Mariano Martinez Peck wrote: > > > Hi guys...with just 2 little methods, I am able to add a button to the > debuger and a button to the context of the debugger, to copy the stakctrace > to clipboard. > > Going to PharoDebug.log is anoying: > > > > 1) I never know where my image is, so I first need to do print Smalltlak > imagePharo > > 2) then I need to go to such folder, and open the PharoDebug.log > > 3) most of the times, PharoDebug has appended a lot of other (un) issues > so it is quite confusing to use such file for a bug report. Hence I need to: > > 4) remove PharoDebug.log and > > 5) Reproduce my problem again, so that to generate a new PharoDebug.log > > 6) finally search it again, open, and do the copy paste :) > > > > So....I think it should be muuuch easier from the debugger. So I added > two possibilities > > > > 1) copy to clipboard from the "pre debugger windows" > > See attached screenshot. > > > > 2) copy to clipboard from the debugger context menu. > > See attached screenshot. > > > > So...do you like it? which one do you want of them ? both ? > > > > Cheers > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > <pre debugger .png><debugger context menu.png> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] Do you want the option to copy a stacktrace to clipboard?

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 10:07 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > But is it linking the debugger to host whatever? > > No...it just copy past the text which was written in a stream. Look the changeset > On Apr 26, 2011, at 9:59 PM, Mariano Martinez Peck wrote: > > > Hi guys...with just 2 little methods, I am able to add a button to the > debuger and a button to the context of the debugger, to copy the stakctrace > to clipboard. > > Going to PharoDebug.log is anoying: > > > > 1) I never know where my image is, so I first need to do print Smalltlak > imagePharo > > 2) then I need to go to such folder, and open the PharoDebug.log > > 3) most of the times, PharoDebug has appended a lot of other (un) issues > so it is quite confusing to use such file for a bug report. Hence I need to: > > 4) remove PharoDebug.log and > > 5) Reproduce my problem again, so that to generate a new PharoDebug.log > > 6) finally search it again, open, and do the copy paste :) > > > > So....I think it should be muuuch easier from the debugger. So I added > two possibilities > > > > 1) copy to clipboard from the "pre debugger windows" > > See attached screenshot. > > > > 2) copy to clipboard from the debugger context menu. > > See attached screenshot. > > > > So...do you like it? which one do you want of them ? both ? > > > > Cheers > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > <pre debugger .png><debugger context menu.png> > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] Do you want the option to copy a stacktrace to clipboard?

by StÃ©phane Ducasse

But is it linking the debugger to host whatever? On Apr 26, 2011, at 9:59 PM, Mariano Martinez Peck wrote: > Hi guys...with just 2 little methods, I am able to add a button to the debuger and a button to the context of the debugger, to copy the stakctrace to clipboard. > Going to PharoDebug.log is anoying: > > 1) I never know where my image is, so I first need to do print Smalltlak imagePharo > 2) then I need to go to such folder, and open the PharoDebug.log > 3) most of the times, PharoDebug has appended a lot of other (un) issues so it is quite confusing to use such file for a bug report. Hence I need to: > 4) remove PharoDebug.log and > 5) Reproduce my problem again, so that to generate a new PharoDebug.log > 6) finally search it again, open, and do the copy paste :) > > So....I think it should be muuuch easier from the debugger. So I added two possibilities > > 1) copy to clipboard from the "pre debugger windows" > See attached screenshot. > > 2) copy to clipboard from the debugger context menu. > See attached screenshot. > > So...do you like it? which one do you want of them ? both ? > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > > <pre debugger .png><debugger context menu.png>

April 26, 2011

Re: [Pharo-project] Do you want the option to copy a stacktrace to clipboard?

by Guillermo Polito

+1 :) This solves my needs of putting the stack trace into the transcript :P. On Tue, Apr 26, 2011 at 4:59 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys...with just 2 little methods, I am able to add a button to the > debuger and a button to the context of the debugger, to copy the stakctrace > to clipboard. > Going to PharoDebug.log is anoying: > > 1) I never know where my image is, so I first need to do print Smalltlak > imagePharo > 2) then I need to go to such folder, and open the PharoDebug.log > 3) most of the times, PharoDebug has appended a lot of other (un) issues so > it is quite confusing to use such file for a bug report. Hence I need to: > 4) remove PharoDebug.log and > 5) Reproduce my problem again, so that to generate a new PharoDebug.log > 6) finally search it again, open, and do the copy paste :) > > So....I think it should be muuuch easier from the debugger. So I added two > possibilities > > 1) copy to clipboard from the "pre debugger windows" > See attached screenshot. > > 2) copy to clipboard from the debugger context menu. > See attached screenshot. > > So...do you like it? which one do you want of them ? both ? > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > >

April 26, 2011

[Pharo-project] Monticello doesn't always call all class side #initalize ?? [WAS] Re: a problem with Zinc on Pharo 1.1.1

by Mariano Martinez Peck

On Tue, Apr 26, 2011 at 9:31 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > > On 26 Apr 2011, at 20:39, Mariano Martinez Peck wrote: > > > Second, I've seen that problem too. I am sure that when loading a new > version of a certain package, some class side #initialize are not called. > When? which ones? I have no idea. > > > > I couldn't reproduce it. Can you? > > I can't figure it out either, but I haven't really looked deeply into it. > > As far as I can tell it just doesn't work: I guess #initialize is only > called when the class is new or maybe when its definition is changed, maybe > when the #initialize method changes, but certainly not all the time when you > load new(er) versions of methods of that class. Maybe that is too much to > expect, I don't know, it would be handy. > > So when your #initialize calls say #initializeConstants and only that > method is changed, you have a problem. > > Maybe somebody else knows ? > > Sven > > > > -- Mariano http://marianopeck.wordpress.com

April 26, 2011

[Pharo-project] Do you want the option to copy a stacktrace to clipboard?

by Mariano Martinez Peck

Hi guys...with just 2 little methods, I am able to add a button to the debuger and a button to the context of the debugger, to copy the stakctrace to clipboard. Going to PharoDebug.log is anoying: 1) I never know where my image is, so I first need to do print Smalltlak imagePharo 2) then I need to go to such folder, and open the PharoDebug.log 3) most of the times, PharoDebug has appended a lot of other (un) issues so it is quite confusing to use such file for a bug report. Hence I need to: 4) remove PharoDebug.log and 5) Reproduce my problem again, so that to generate a new PharoDebug.log 6) finally search it again, open, and do the copy paste :) So....I think it should be muuuch easier from the debugger. So I added two possibilities 1) copy to clipboard from the "pre debugger windows" See attached screenshot. 2) copy to clipboard from the debugger context menu. See attached screenshot. So...do you like it? which one do you want of them ? both ? Cheers -- Mariano http://marianopeck.wordpress.com

April 26, 2011

Re: [Pharo-project] a problem with Zinc on Pharo 1.1.1

by Sven Van Caekenberghe

On 26 Apr 2011, at 20:39, Mariano Martinez Peck wrote: > Second, I've seen that problem too. I am sure that when loading a new version of a certain package, some class side #initialize are not called. When? which ones? I have no idea. > > I couldn't reproduce it. Can you? I can't figure it out either, but I haven't really looked deeply into it. As far as I can tell it just doesn't work: I guess #initialize is only called when the class is new or maybe when its definition is changed, maybe when the #initialize method changes, but certainly not all the time when you load new(er) versions of methods of that class. Maybe that is too much to expect, I don't know, it would be handy. So when your #initialize calls say #initializeConstants and only that method is changed, you have a problem. Maybe somebody else knows ? Sven

April 26, 2011

[Pharo-project] NetNameResolver localHostName - Mac OS always returns an ip address string

by Chris Cunnington

http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/146581.ht… NetNameResolver chooses an interface in an almost random manner. It can't be configured as the logic is baked into the VM. The thread above has some details concerning the topic and mentions a workaround. (You might think that being on a Mac, you could make a configuration change in the plist that comes with the VM and then restart. But I don't think there are any arguments in the plist for network interfaces.) Chris

April 26, 2011