--- Comment #15 from 2010-08-26 10:12:08 PDT ---
(In reply to comment #14)
> I'm not assuming anything about the memory layout.  GC.qalloc gives me a block
> of data, and I'm using the data.  Its interface is well defined without any
> hidden assumptions.

That mess is mostly gone, but there's still that commented stuff. Will it be
readded later?

> Besides, you are calling the same runtime functions, just using a different
> interface.  I don't see how one is more "dirty" than the other, we are both
> using well-documented runtime functions.

It doesn't zero the additional memory returned by GC.extend().
If precise GC is introduced, that won't be handled correctly either.

> Your code calls the lifetime runtime functions, which call the GC runtime
> functions.  My code just calls the GC functions, skipping the lifetime
> functions.  Like your code, mine only calls runtime functions on exhaustion.

The only real overhead is due to array initialization.
If that is really so important, the runtime should provide a clean interface to
allocate arrays uninitialized (or zeroed if not NO_SCAN). Basically a
_d_arraysetlengthT without the initialization code. That would be useful for
other code too; most time you create an array, you overwrite all its contents

Keep in mind that optimizing the runtime code might be more worthwhile than
optimizing Appender.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to