Created attachment 67526 [details] possible Patch libxml provides a function called xmlMemSetup() (http://xmlsoft.org/html/libxml-xmlmemory.html#xmlMemSetup), where we can set the memory access functions. The strange thing on my machine was, that it was slower with WTF:fastMalloc. Any ideas? I tried a ~10MB SVG and stopped the time from first doWrite until doEnd with a GTK release build on linux.
Why is the patch flagged for review when you claim it makes things slower?
(In reply to comment #1) > Why is the patch flagged for review when you claim it makes things slower? IMHO it should get faster. Maybe I miss something? That's the reason. Feel free to remove the r?.
Comment on attachment 67526 [details] possible Patch Marking as r- as the author mentioned this was a performance regression. Our policy towards performance is to take changes that measure as performance wins, not changes that we hope may be faster. I’d suggest that this bug be closed unless there’s some compelling reason to think that we can make this in to a performance win.
(In reply to comment #3) > (From update of attachment 67526 [details]) > Marking as r- as the author mentioned this was a performance regression. Our policy towards performance is to take changes that measure as performance wins, not changes that we hope may be faster. I’d suggest that this bug be closed unless there’s some compelling reason to think that we can make this in to a performance win. Do you have any idea why this is (on my machine!!) slower? Shouldn't it be faster with fastMalloc? Maybe someone can try on a other platform before we close the bug?
Using of TCmalloc doesn't mean automatic performance improvement, especially not for external libraries. I agree with Mark, we should take this change.
> I agree with Mark, we should take this change. We should not take this change.