--- Comment #16 from Vladimir Panteleev <> 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:
------- You are receiving this mail because: -------

Reply via email to