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: -------
