http://d.puremagic.com/issues/show_bug.cgi?id=5813
--- Comment #15 from Rob Jacques <sandf...@jhu.edu> 2012-01-02 12:02:40 PST --- 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? Thanks for all this work. (In reply to comment #12) > 1) Extra indirection levels are performance killers I agree. > 2) I failed to create a chained appender (like the one in this patch) that was > faster than a copying one, for my test cases The primary purpose of a chained appender is to minimize memory leaks, memory usage and maximizing large scale performance. 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. > 3) At least on Windows and with short strings, simple slice copy trumps all > memcpy implementations I tried > 4) You can write a nextCapacity function with no branches Good to know. > 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------