Re: cvs commit: parrot/t/pmc resizablestringarray.t
Nicholas Clark
> +output_is(<<'CODE', <<'OUTPUT', 'pop many values');
> + new P0, .ResizableStringArray
> + set I0, 0
> +L1: set S0, I0
> + set P0[I0], S0
> + inc I0
> + lt I0, 100000, L1
^this^
really really hurts.
The test seems to hang. Actually, it's just taking forever (not sure how
close an approximation that is) for --gc-debug. If I run without -gc-debug
it completes.
Timings for a run of 10,000 (not 100,000) on a 1.2 GHz Powerbook are
$ time ./parrot --gc-debug t/pmc/resizablestringarray_11.pasm
ok
real 0m18.438s
user 0m15.880s
sys 0m0.420s
whereas 9000 is
real 0m18.438s
user 0m15.880s
sys 0m0.420s
so the slowdown is worse than linear.
It's also tying up a fast x86 FreeBSD box, so it's not something PPC or
OS X specific.
Did it really need to be higher than (say) 5000?
Nicholas Clark
Leopold Toetsch
> On Mon, Jan 03, 2005 at 10:13:53PM -0000, Simon Glover wrote:
>> + lt I0, 100000, L1
> ^this^
> really really hurts.
It's already reduced in CVS.
> Nicholas Clark
leo
Simon Glover
On Tue, 4 Jan 2005, Nicholas Clark wrote:
> On Mon, Jan 03, 2005 at 10:13:53PM -0000, Simon Glover wrote:
>
> > +output_is(<<'CODE', <<'OUTPUT', 'pop many values');
> > + new P0, .ResizableStringArray
> > + set I0, 0
> > +L1: set S0, I0
> > + set P0[I0], S0
> > + inc I0
> > + lt I0, 100000, L1
>
> ^this^
>
> really really hurts.
Sorry about that - I converted the test from an existing one for
ResizableFloatArray, but forgot that in the string case there's a
much higher load on the GC system due to all the string headers.
I see no reason why it shouldn't be smaller.
Simon
Leopold Toetsch
> Sorry about that - I converted the test from an existing one for
> ResizableFloatArray, but forgot that in the string case there's a
> much higher load on the GC system due to all the string headers.
Actually the problem aren't the string headers per se. The string
compares were triggering 100.000 DOD runs with --gc-debug.
> Simon
leo