Sean O'Rourke wrote:
> But really I think the way to go would be a generational collector --
after
> we've collected a pool once or twice (or after we've failed to recover
> more than x% from it on the previous run), we put it off to the side and
> compact (indeed, look at) it less often. New obj
On Fri, 24 May 2002, Peter Gibbs wrote:
> My current work is based on counting the size of freed buffers - yes,
> this adds some overhead in free_unused_buffers, but it seems like it
> may be worth it - and only doing compaction runs when a predefined
> fraction of the pool size is available for f
Sean O'Rourke wrote:
> >I took a look at what was going on, and found that the GC probably needs
a
> >good tuning. For the 20K file, parrot is doing 217 collections of the
> >string pool, the last 102 of which reclaim less than 10% of the pool.
> >Changing compact_string_pool() to increase the po
At 7:01 PM -0700 5/22/02, Sean O'Rourke wrote:
>I took a look at what was going on, and found that the GC probably needs a
>good tuning. For the 20K file, parrot is doing 217 collections of the
>string pool, the last 102 of which reclaim less than 10% of the pool.
>Changing compact_string_pool()
I prefer it to work like this:
set S0,""
set IO,42
pack S0, 4, I0 ,0
length I1, S0 # is 4
pack S0, 4, I0
length I1, S0 # is 8
pack S0, 4, I0, 1 # no segv :)
length I1, S0 # is 10004
Patch is already applied.
Daniel Grunblatt.
On Thu, 23 May 2002, Sean O'Rourke wrot
Let's try "patch that compiles"...
/s
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.143
diff -u -p -r1.143 core.ops
--- core.ops20 May 2002 17:52:28 - 1.143
+++ core.ops23 May 2002 15:03:31 -
@@ -1957,11 +1957,17 @@ inline op pack(inout STR, in INT, in
On Thu, 23 May 2002, Daniel Grunblatt wrote:
>
> On Wed, 22 May 2002, Sean O'Rourke wrote:
>
> > that pack() can't handle null bytes makes it a bit more complicated (and
> Exactly how do you want it to handle null bytes?
Nevermind -- sorry 'bout that. There's a little wierdness in there, but
it
On Wed, 22 May 2002, Sean O'Rourke wrote:
> This is an implementation of LZW compression in Parrot assembly. The fact
> that pack() can't handle null bytes makes it a bit more complicated (and
> limited) than it has to be, but for just text files, it seems to work just
> fine. It's probably a
I took a look at what was going on, and found that the GC probably needs a
good tuning. For the 20K file, parrot is doing 217 collections of the
string pool, the last 102 of which reclaim less than 10% of the pool.
Changing compact_string_pool() to increase the pool size by a factor of
(0.5 - pct
At 12:41 PM 5/22/2002 -0700, Sean O'Rourke wrote:
>This is an implementation of LZW compression in Parrot assembly. The fact
>that pack() can't handle null bytes makes it a bit more complicated (and
>limited) than it has to be, but for just text files, it seems to work just
>fine. It's probably
This is an implementation of LZW compression in Parrot assembly. The fact
that pack() can't handle null bytes makes it a bit more complicated (and
limited) than it has to be, but for just text files, it seems to work just
fine. It's probably a decent stress test for the hash PMC, but especially
11 matches
Mail list logo
