45735 2010-09-14 01:32:13 -0700 Use fastMalloc in libxml 2010-09-15 01:51:35 -0700 1 1 1 Unclassified WebKit XML 528+ (Nightly build) All All UNCONFIRMED P2 Normal --- 43085 0 paroga webkit-unassigned zoltan oldest_to_newest 278770 0 67526 paroga 2010-09-14 01:32:13 -0700 Created attachment 67526 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. 279042 1 mrowe 2010-09-14 11:23:21 -0700 Why is the patch flagged for review when you claim it makes things slower? 279049 2 paroga 2010-09-14 11:38:46 -0700 (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?. 279074 3 67526 mrowe 2010-09-14 12:17:41 -0700 Comment on attachment 67526 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. 279076 4 paroga 2010-09-14 12:20:57 -0700 (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? 279454 5 zoltan 2010-09-15 01:17:31 -0700 Using of TCmalloc doesn't mean automatic performance improvement, especially not for external libraries. I agree with Mark, we should take this change. 279469 6 zoltan 2010-09-15 01:51:35 -0700 > I agree with Mark, we should take this change. We should not take this change. 67526 2010-09-14 01:32:13 -0700 2010-09-14 12:17:40 -0700 possible Patch xmlmemory.patch text/plain 1316 paroga SW5kZXg6IFdlYkNvcmUvZG9tL1hNTERvY3VtZW50UGFyc2VyTGlieG1sMi5jcHAKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gV2ViQ29yZS9kb20vWE1MRG9jdW1lbnRQYXJzZXJMaWJ4bWwyLmNwcCAgICAocmV2aXNp b24gNjY5OTcpCisrKyBXZWJDb3JlL2RvbS9YTUxEb2N1bWVudFBhcnNlckxpYnhtbDIuY3BwICAg ICh3b3JraW5nIGNvcHkpCkBAIC01MSw2ICs1Myw3IEBACiAjaW5jbHVkZSAiVHJhbnNmb3JtU291 cmNlLmgiCiAjaW5jbHVkZSAiWE1MTlNOYW1lcy5oIgogI2luY2x1ZGUgIlhNTERvY3VtZW50UGFy c2VyU2NvcGUuaCIKKyNpbmNsdWRlIDxsaWJ4bWwveG1sbWVtb3J5Lmg+CiAjaW5jbHVkZSA8bGli eG1sL3BhcnNlci5oPgogI2luY2x1ZGUgPGxpYnhtbC9wYXJzZXJJbnRlcm5hbHMuaD4KICNpbmNs dWRlIDx3dGYvdGV4dC9DU3RyaW5nLmg+CkBAIC00NzcsNiArNDgyLDcgQEAKIFBhc3NSZWZQdHI8 WE1MUGFyc2VyQ29udGV4dD4gWE1MUGFyc2VyQ29udGV4dDo6Y3JlYXRlU3RyaW5nUGFyc2VyKHht bFNBWEhhbmRsZXJQdHIgaGFuZGxlcnMsIHZvaWQqIHVzZXJEYXRhKQogewogICAgIGlmICghZGlk SW5pdCkgeworICAgICAgICB4bWxNZW1TZXR1cChmYXN0RnJlZSwgZmFzdE1hbGxvYywgZmFzdFJl YWxsb2MsIGZhc3RTdHJEdXApOwogICAgICAgICB4bWxJbml0UGFyc2VyKCk7CiAgICAgICAgIHht bFJlZ2lzdGVySW5wdXRDYWxsYmFja3MobWF0Y2hGdW5jLCBvcGVuRnVuYywgcmVhZEZ1bmMsIGNs b3NlRnVuYyk7CiAgICAgICAgIHhtbFJlZ2lzdGVyT3V0cHV0Q2FsbGJhY2tzKG1hdGNoRnVuYywg b3BlbkZ1bmMsIHdyaXRlRnVuYywgY2xvc2VGdW5jKTsKQEAgLTQ5Nyw2ICs1MDMsNyBAQAogUGFz c1JlZlB0cjxYTUxQYXJzZXJDb250ZXh0PiBYTUxQYXJzZXJDb250ZXh0OjpjcmVhdGVNZW1vcnlQ YXJzZXIoeG1sU0FYSGFuZGxlclB0ciBoYW5kbGVycywgdm9pZCogdXNlckRhdGEsIGNvbnN0IGNo YXIqIGNodW5rKQogewogICAgIGlmICghZGlkSW5pdCkgeworICAgICAgICB4bWxNZW1TZXR1cChm YXN0RnJlZSwgZmFzdE1hbGxvYywgZmFzdFJlYWxsb2MsIGZhc3RTdHJEdXApOwogICAgICAgICB4 bWxJbml0UGFyc2VyKCk7CiAgICAgICAgIHhtbFJlZ2lzdGVySW5wdXRDYWxsYmFja3MobWF0Y2hG dW5jLCBvcGVuRnVuYywgcmVhZEZ1bmMsIGNsb3NlRnVuYyk7CiAgICAgICAgIHhtbFJlZ2lzdGVy T3V0cHV0Q2FsbGJhY2tzKG1hdGNoRnVuYywgb3BlbkZ1bmMsIHdyaXRlRnVuYywgY2xvc2VGdW5j KTsKIAo=