[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=5813



--- Comment #15 from Rob Jacques <sandford at 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: -------