--- Comment #16 from Vladimir Panteleev <thecybersha...@gmail.com> 2012-01-02
12:10:18 PST ---
(In reply to comment #15)
> Vladimir, the code in
> seems to be under the MPL, which isn't Phobos compatible. What license is the
> code in:
> 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: -------