--- 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
> 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
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------