[chromium-dev] Re: Allocator Choice
On Tue, Aug 11, 2009 at 8:25 PM, Mike Belshembel...@google.com wrote: Unlike Obama's plan for healthcare, this CL is about giving you more choice. Political comments are off-topic for this list, I think. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Allocator Choice
On Tue, Aug 11, 2009 at 9:57 PM, Dean McNamee de...@chromium.org wrote: Do we have numbers on how the 4 allocates compare on those tests (page cycler, etc)? I do - I sent some of them around a few days ago. Summary: jemalloc and tcmalloc are pretty close; where jemalloc is a little more compact and tcmalloc is a smidge faster. Overall jemalloc looks pretty darned good. The source to tcmalloc is more hackable though. The windows heap varies by platform, as they did a lot of work on the Vista heap, including making LFH the default. But both jemalloc and tcmalloc considerably outperform the windows heaps both on size and perf. Mike On Tue, Aug 11, 2009 at 8:25 PM, Mike Belshembel...@google.com wrote: In an effort to make it easier to test debugging heaps and allocators, I just landed a changelist which makes our allocators switchable at runtime. Unlike Obama's plan for healthcare, this CL is about giving you more choice. From an environment variable, you can now switch between 4 different allocators. set CHROME_ALLOCATOR=tcmalloc // default - use TC Malloc set CHROME_ALLOCATOR=jemalloc // use JEMalloc, the allocator also used in firefox set CHROME_ALLOCATOR=winheap // use the built in windows heap set CHROME_ALLOCATOR=winlfh // use the low-fragmentation windows heap This change also contains a fix to tcmalloc to more aggressively return pages (in other words, actually return them sometimes). Without this fix, Chrome grows but doesn't shrink. As a result, this change *DOES* have a negative performance impact on chrome (we're now returning pages fairly aggressively) Good news: - Our memory test shows a 4% drop (not terribly significant) http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150graph=commit_charge Neutral news: - The Moz page cycler shows no change: http://build.chromium.org/buildbot/perf/vista-release-dual-core/moz/report.html?history=150 Bad news - The JS page cycler shows a 3% drop. http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=150 I'm working on this. Let me know if you have problems or feedback. Also, if you do play around with the allocator choices, let me know your experience. Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Allocator Choice
Does all this work with Purify? Linus On Wed, Aug 12, 2009 at 9:09 AM, Mike Belshe mbel...@google.com wrote: On Tue, Aug 11, 2009 at 9:57 PM, Dean McNamee de...@chromium.org wrote: Do we have numbers on how the 4 allocates compare on those tests (page cycler, etc)? I do - I sent some of them around a few days ago. Summary: jemalloc and tcmalloc are pretty close; where jemalloc is a little more compact and tcmalloc is a smidge faster. Overall jemalloc looks pretty darned good. The source to tcmalloc is more hackable though. The windows heap varies by platform, as they did a lot of work on the Vista heap, including making LFH the default. But both jemalloc and tcmalloc considerably outperform the windows heaps both on size and perf. Mike On Tue, Aug 11, 2009 at 8:25 PM, Mike Belshembel...@google.com wrote: In an effort to make it easier to test debugging heaps and allocators, I just landed a changelist which makes our allocators switchable at runtime. Unlike Obama's plan for healthcare, this CL is about giving you more choice. From an environment variable, you can now switch between 4 different allocators. set CHROME_ALLOCATOR=tcmalloc // default - use TC Malloc set CHROME_ALLOCATOR=jemalloc // use JEMalloc, the allocator also used in firefox set CHROME_ALLOCATOR=winheap // use the built in windows heap set CHROME_ALLOCATOR=winlfh // use the low-fragmentation windows heap This change also contains a fix to tcmalloc to more aggressively return pages (in other words, actually return them sometimes). Without this fix, Chrome grows but doesn't shrink. As a result, this change *DOES* have a negative performance impact on chrome (we're now returning pages fairly aggressively) Good news: - Our memory test shows a 4% drop (not terribly significant) http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150graph=commit_charge Neutral news: - The Moz page cycler shows no change: http://build.chromium.org/buildbot/perf/vista-release-dual-core/moz/report.html?history=150 Bad news - The JS page cycler shows a 3% drop. http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=150 I'm working on this. Let me know if you have problems or feedback. Also, if you do play around with the allocator choices, let me know your experience. Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Allocator Choice
Yes Mike On Wed, Aug 12, 2009 at 9:37 AM, Linus Upson li...@google.com wrote: Does all this work with Purify? Linus On Wed, Aug 12, 2009 at 9:09 AM, Mike Belshe mbel...@google.com wrote: On Tue, Aug 11, 2009 at 9:57 PM, Dean McNamee de...@chromium.org wrote: Do we have numbers on how the 4 allocates compare on those tests (page cycler, etc)? I do - I sent some of them around a few days ago. Summary: jemalloc and tcmalloc are pretty close; where jemalloc is a little more compact and tcmalloc is a smidge faster. Overall jemalloc looks pretty darned good. The source to tcmalloc is more hackable though. The windows heap varies by platform, as they did a lot of work on the Vista heap, including making LFH the default. But both jemalloc and tcmalloc considerably outperform the windows heaps both on size and perf. Mike On Tue, Aug 11, 2009 at 8:25 PM, Mike Belshembel...@google.com wrote: In an effort to make it easier to test debugging heaps and allocators, I just landed a changelist which makes our allocators switchable at runtime. Unlike Obama's plan for healthcare, this CL is about giving you more choice. From an environment variable, you can now switch between 4 different allocators. set CHROME_ALLOCATOR=tcmalloc // default - use TC Malloc set CHROME_ALLOCATOR=jemalloc // use JEMalloc, the allocator also used in firefox set CHROME_ALLOCATOR=winheap // use the built in windows heap set CHROME_ALLOCATOR=winlfh // use the low-fragmentation windows heap This change also contains a fix to tcmalloc to more aggressively return pages (in other words, actually return them sometimes). Without this fix, Chrome grows but doesn't shrink. As a result, this change *DOES* have a negative performance impact on chrome (we're now returning pages fairly aggressively) Good news: - Our memory test shows a 4% drop (not terribly significant) http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150graph=commit_charge Neutral news: - The Moz page cycler shows no change: http://build.chromium.org/buildbot/perf/vista-release-dual-core/moz/report.html?history=150 Bad news - The JS page cycler shows a 3% drop. http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=150 I'm working on this. Let me know if you have problems or feedback. Also, if you do play around with the allocator choices, let me know your experience. Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Allocator Choice
Do we have numbers on how the 4 allocates compare on those tests (page cycler, etc)? On Tue, Aug 11, 2009 at 8:25 PM, Mike Belshembel...@google.com wrote: In an effort to make it easier to test debugging heaps and allocators, I just landed a changelist which makes our allocators switchable at runtime. Unlike Obama's plan for healthcare, this CL is about giving you more choice. From an environment variable, you can now switch between 4 different allocators. set CHROME_ALLOCATOR=tcmalloc // default - use TC Malloc set CHROME_ALLOCATOR=jemalloc // use JEMalloc, the allocator also used in firefox set CHROME_ALLOCATOR=winheap // use the built in windows heap set CHROME_ALLOCATOR=winlfh // use the low-fragmentation windows heap This change also contains a fix to tcmalloc to more aggressively return pages (in other words, actually return them sometimes). Without this fix, Chrome grows but doesn't shrink. As a result, this change *DOES* have a negative performance impact on chrome (we're now returning pages fairly aggressively) Good news: - Our memory test shows a 4% drop (not terribly significant) http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150graph=commit_charge Neutral news: - The Moz page cycler shows no change: http://build.chromium.org/buildbot/perf/vista-release-dual-core/moz/report.html?history=150 Bad news - The JS page cycler shows a 3% drop. http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=150 I'm working on this. Let me know if you have problems or feedback. Also, if you do play around with the allocator choices, let me know your experience. Mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
