http://d.puremagic.com/issues/show_bug.cgi?id=4681



--- Comment #15 from nfx...@gmail.com 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
anyway.

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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Reply via email to