--- Comment #16 from Steven Schveighoffer <schvei...@yahoo.com> 2011-02-24
18:45:01 PST ---
(In reply to comment #15)
from that wiki page:
Also note that a Tree2 benchmark also exists, but it seems to run in either 12
or 0 seconds, randomly, no matter what patches are applied, for reasons I don't
this pertains to bug 5650
I have seen the same anomaly (although mine must be slower hardware, it varies
between 20+ and .9 seconds).
My theory is that false pointers are keeping the elements in memory, so the GC
never frees them. It is *definitely* the GC's fullCollect that is causing the
slowdown, because while debugging (and printing out every 100 loops), you can
ctrl-c to pause, and it's always in the collect cycle.
Basically, the program is so deterministic, that the only think I can think of
that changes between good and bad runs is the address space given to the heap
by the OS.
I sort of tested this theory by adding this line to the code:
Here are the results of running a bunch of times (the times follow the address
Most of the time, the smaller the number, the more likely it is to run slowly.
There are, however, some outliers.
What does this data mean? It may mean nothing, but it does seem to strongly
correlate with address selection. I can't think of any other reason the code
would be so drastically different from one run to the next. Does this mean
false pointers are the problem? Not sure, but it's all I can think of for now.
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------