And there's another interesting observation. In Morphic, the delay because of tenuring is much larger than in MVC. This is probably because Morphic creates much more short-lived object garbage.
Umm, 'splain again why tenuring would make Morphic feel slow?
If Morphic creates lots of short-lived objects, then much (most?) of those objects won't survive long enough to get tenured; besides, isn't tenuring only done every now and then, when incremental GC's get too long (too many survivors) or the root table gets full?
Thinking about this, could this be the reason, why Morphic always feels a little bit slower than MVC? If yes, then the best approach to speed up Morphic would be to reduce the number of temporary objects...
Creating lots of temporary objects will trigger lots more minor GC's which could make it run slower. However, there are several improvements to the collector that could improve this. Dynamically adjusting the allocation threshold (currently fixed at 4000) and tenuring policy could reduce the frequency of minor GC's, giving those short-lived objects more time to die while keeping minor GC duration below the 10ms threshold.
Looking at the collector, though, it looks like the reason for the 4000 object allocation threshold is because the relocation phase doesn't deal very well with the case where more than 2000 objects need to be relocated in a single minor collection, although this could be tweaked.
At 08:51 31.05.00 -0500, you wrote:
And there's another interesting observation. In Morphic, the delay because of tenuring is much larger than in MVC. This is probably because Morphic creates much more short-lived object garbage.
Umm, 'splain again why tenuring would make Morphic feel slow?
My guess was that these objects aren't short-lived enough. If they survive one GC, they need to be copied - and this might take quite a few milliseconds. I'd guess that Morphic creates too many Point and Rectangle objects just to draw one screen. And as there are most often stepping objects which require continuous screen updates, it will GC quite often.
So perhaps a "Smalltalk vmParameterAt: 5 put: 10000" will reduce the number of GCs. Could you please explain why increasing this value has problems?
Creating lots of temporary objects will trigger lots more minor GC's which could make it run slower.
Yes, that was my argument. To prove it, I created a simple test for morphic. Without any interaction and just a workspace (and of course my InfoStringMorph) open, I get about 2 incremental GCs per second.
Selecting text in the workspace raises the GCs/sec to 25!
If I increment the object count to 10000, I get only 9 GCs/sec when selecting text in that same workspace. I think, this proves that objects live too long. My system spends about 10 milliseconds or 1% of all time in GCs per second. (0.3% if count = 10000)
If I allocate a one-million-elements array, spends about 230 milliseconds or 23% of all time in GC per second (12% if count = 10000)! This means, the incremental GC doesn't scale well at all.
bye
Stefan,
Stefan Matthias Aust wrote:
At 08:51 31.05.00 -0500, you wrote:
And there's another interesting observation. In Morphic, the delay because of tenuring is much larger than in MVC. This is probably because Morphic creates much more short-lived object garbage.
Umm, 'splain again why tenuring would make Morphic feel slow?
My guess was that these objects aren't short-lived enough. If they survive one GC, they need to be copied - and this might take quite a few milliseconds. I'd guess that Morphic creates too many Point and Rectangle objects just to draw one screen. And as there are most often stepping objects which require continuous screen updates, it will GC quite often.
So perhaps a "Smalltalk vmParameterAt: 5 put: 10000" will reduce the number of GCs. Could you please explain why increasing this value has problems?
Creating lots of temporary objects will trigger lots more minor GC's which could make it run slower.
Yes, that was my argument. To prove it, I created a simple test for morphic. Without any interaction and just a workspace (and of course my InfoStringMorph) open, I get about 2 incremental GCs per second.
What was the block you have given to the InfoStringMorph to get your results?
Greetings
Stephan
Selecting text in the workspace raises the GCs/sec to 25!
If I increment the object count to 10000, I get only 9 GCs/sec when selecting text in that same workspace. I think, this proves that objects live too long. My system spends about 10 milliseconds or 1% of all time in GCs per second. (0.3% if count = 10000)
If I allocate a one-million-elements array, spends about 230 milliseconds or 23% of all time in GC per second (12% if count = 10000)! This means, the incremental GC doesn't scale well at all.
bye
Name: InfoStringMorph-sma.cs
InfoStringMorph-sma.cs Type: unspecified type (application/octet-stream) Encoding: base64
squeak-dev@lists.squeakfoundation.org