http://d.puremagic.com/issues/show_bug.cgi?id=5813
--- Comment #16 from Vladimir Panteleev <thecybersha...@gmail.com> 2012-01-02 12:10:18 PST --- (In reply to comment #15) > Vladimir, the code in > https://github.com/CyberShadow/ae/blob/master/utils/appender.d > seems to be under the MPL, which isn't Phobos compatible. What license is the > code in: > https://github.com/CyberShadow/DAppenderResearch > under? If it's not under a Boost compatible license, could you make it > available under one? Sure, consider my code in DAppenderResearch public domain. ae is mainly MPL because it was the least restrictive license other contributors agreed on. > That said, I did write a faster > chained appender for your benchmarks; however I did this by initializing the > appender with a page of memory, which definitely should not be the default > behavior. That said, one viable strategy for appender would be to keep 1 page > of memory around as a scratch pad. Can you elaborate on this (or share your code)? > > 5) It's better to store an "end" pointer than a "capacity" integer > I'll look into this, but this you can not make this judgment call based on the > performance of a char appender. The issue is that anything with a power of 2 > T.sizeof performs integer multiplication/division using shift operations > instead of the actual underlying instructions, both of which are very slow. I'm not following your explanation. I don't see how element size plays against my conclusion - in fact, as far as I can see, calculating a "position-after-append" pointer and comparing it to an "end" pointer is going to be faster, because you will need to update the position anyway. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
