At 9:47 AM -0500 2/28/02, Bryan C. Warnock wrote:
>Creeping string length. (You may want to verify the program actually still
>works! :-)
Looks good. Applied, thanks.
--
Dan
--"it's like this"---
Dan
At 9:03 AM -0500 2/28/02, Bryan C. Warnock wrote:
>When you clone a constant, it ain't constant no mo'.
>This patch helps a lot, but doesn't fix everything.
Applied, thanks.
--
Dan
--"it's like this"---
Creeping string length. (You may want to verify the program actually still
works! :-)
Index: examples/assembly/life.pasm
===
RCS file: /home/perlcvs/parrot/examples/assembly/life.pasm,v
retrieving revision 1.6
diff -u -r1.6 life.p
On Thursday 28 February 2002 08:32, Bryan C. Warnock wrote:
>
> The second call to new_string_header() in each generation loses one entry
> in the string header pool during DOD. The twelfth call to
> new_string_header() in each generation loses the second. *That* should be
> enough info to track
On Thursday 28 February 2002 01:12, Bryan C. Warnock wrote:
> (Starts off at 90 recovered entries, then 88, 86, ..., 4, 2, 1, 128, 126,
> etc.) The number of entries before decreasing seems to increase. I'll
> see if I can extract a pattern.
>
> It's similar to the previous patterns, albeit a li
Bryan C. Warnock:
# On Wednesday 27 February 2002 23:34, Bryan C. Warnock wrote:
# > I did a graphical mapping of the DOD and GC calls, and the
# GC pattern was
# > interesting. (Indicative of a leak. I'm going to patch
# the output to
# > show a generation loop, and then post and interpret.)
#
On Thursday 28 February 2002 00:17, Bryan C. Warnock wrote:
> On Wednesday 27 February 2002 23:34, Bryan C. Warnock wrote:
> > I did a graphical mapping of the DOD and GC calls, and the GC pattern
> > was interesting. (Indicative of a leak. I'm going to patch the output
> > to show a generation
On Wednesday 27 February 2002 23:34, Bryan C. Warnock wrote:
> I did a graphical mapping of the DOD and GC calls, and the GC pattern was
> interesting. (Indicative of a leak. I'm going to patch the output to
> show a generation loop, and then post and interpret.)
Attached (hopefully) is a one-l
At 11:34 PM -0500 2/27/02, Bryan C. Warnock wrote:
>On Wednesday 27 February 2002 20:57, Dan Sugalski wrote:
>> I presume the ### lines were the two that took longest, at 21 seconds
>> each, more or less?
>
>Yeah, as flagged by WorkShop.
Gotcha. Damned expensive, so we'll have to see what we ca
On Wednesday 27 February 2002 20:57, Dan Sugalski wrote:
> I presume the ### lines were the two that took longest, at 21 seconds
> each, more or less?
Yeah, as flagged by WorkShop.
>
> I think some sort of "X full memory allocations per collection"
> scheme would be a good thing, and tuning the
At 8:54 PM -0500 2/27/02, Bryan C. Warnock wrote:
>On Wednesday 27 February 2002 20:19, Bryan C. Warnock wrote:
>> Yowza, you aren't kidding.
>>
>> mark_buffers_unused() and free_unused_buffers() are a minute each in a
> > three minute-and-change run.
>
>I'm guessing you're overiterating, but I
At 8:19 PM -0500 2/27/02, Bryan C. Warnock wrote:
>Yowza, you aren't kidding.
Nope. :(
>mark_buffers_unused() and free_unused_buffers() are a minute each in
>a three minute-and-change run.
That's a good sign I'm doing something wrong. I'm not sure what,
though actually collecting would be my
On Wednesday 27 February 2002 20:19, Bryan C. Warnock wrote:
> Yowza, you aren't kidding.
>
> mark_buffers_unused() and free_unused_buffers() are a minute each in a
> three minute-and-change run.
I'm guessing you're overiterating, but I haven't found where yet.
--
Bryan C. Warnock
[EMAIL PROTEC
13 matches
Mail list logo
