Array new: 1000000 performance question
Marcus Denker
denker at iam.unibe.ch
Tue Jul 20 08:28:15 UTC 2004
Am 20.07.2004 um 04:11 schrieb Jack Keel:
> Hi,
>
> Sorry if this is a known issue.
>
> I discovered a curious performance issue in Squeak (3.7 and 3.6, Mac
> and Windows):
>
> Squeak idling cpu use (2% on 3Ghz XP and 9% on 350 Mhz G3)
> then do it:
> t := Array new: 1000000.
>
> Array allocation is quick but cpu usage jumps to 15% (XP) 35%(on G3)
> and stays there.
> Tried it in VW 7.2 and it didn't do this.
> Using new: 1000 didn't trigger the cpu use either.
>
> Smalltalk garbageCollect. "Fixes it even though the object is still
> instantiated"
>
> What causes this?
>
>
This shows nicely how the garbagecollector works. After starting up, VM
Statistics (you
find this under "help") shows:
uptime 0h0m39s
memory 26,956,320 bytes
old 22,719,428 bytes (84.3%)
young 338,732 bytes (1.3%)
used 23,058,160 bytes (85.5%)
free 3,898,160 bytes (14.5%)
GCs 520 (75ms between GCs)
full 3 totalling 810ms (2.0% uptime), avg 270.0ms
incr 517 totalling 2,241ms (6.0% uptime), avg 4.0ms
tenures 2 (avg 258 GCs/tenure)
Ok. We see that we have an "old" space and a "young" space. Objects are
created in the young space. So after allocation the array, we se:
uptime 0h0m54s
memory 26,957,952 bytes
old 18,561,168 bytes (68.9%)
young 4,379,268 bytes (16.2%)
used 22,940,436 bytes (85.1%)
free 4,017,516 bytes (14.9%)
So your array was created in the young space, as all new objects. Now
the
young space is the only part of the memory that gets garbageCollected
often
(wie call this "incremental GC"). So after the Array was allocated, the
incremental
GC has to clean a huge young space (over 4MB), which takes time.
Normal objects die young, so most garbage can be collected in the young
space and
the young space is not growing that fast.
But some objects live longer (like the Array). They need to be moved to
oldspace.
This happens either when we do a full GC (which moves everything to old
and does
a GC in old). Or by "tenuring" objects from young to old without a GC.
I'm not quite
sure what the tenuring policy is in Squeak, but I think that it just
moves all
Objects of the young space to old space, when the number of surviving
objects exceeds a
certain treshhold after an incr. GC.
This would not take space into account, so just allocating a huge array
does not toggle tenuring.
I think that Visualworks has either a third space for large objects, or
large objects
are created directly in oldspace somhow.
Marcus
More information about the Squeak-dev
mailing list
|