Bug 45735

Summary:

Use fastMalloc in libxml

Product:

WebKit

Reporter:

Patrick R. Gansterer <paroga>

Component:

XML

Assignee:

Nobody <webkit-unassigned>

Status:

UNCONFIRMED

Severity:

Normal

CC:

zoltan

Priority:

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Bug Depends on:

Bug Blocks:

43085

Attachments:

Description	Flags
possible Patch	mrowe: review-, paroga: commit-queue-

Patrick R. Gansterer

Reported 2010-09-14 01:32:13 PDT

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.

Attachments
possible Patch (1.29 KB, patch) 2010-09-14 01:32 PDT, Patrick R. Gansterer	mrowe: review- paroga: commit-queue-	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Mark Rowe (bdash)

Comment 1 2010-09-14 11:23:21 PDT

Why is the patch flagged for review when you claim it makes things slower?

Patrick R. Gansterer

Comment 2 2010-09-14 11:38:46 PDT

(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?.

Mark Rowe (bdash)

Comment 3 2010-09-14 12:17:41 PDT

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.

Patrick R. Gansterer

Comment 4 2010-09-14 12:20:57 PDT

(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?

Zoltan Horvath

Comment 5 2010-09-15 01:17:31 PDT

Using of TCmalloc doesn't mean automatic performance improvement, especially not for external libraries. I agree with Mark, we should take this change.

Zoltan Horvath

Comment 6 2010-09-15 01:51:35 PDT

> I agree with Mark, we should take this change. We should not take this change.

Note You need to log in before you can comment on or make changes to this bug.