[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers
Note: my change was reverted for other reasons.-Darin On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.org wrote: Hey everyone, A performance regression has appeared on the XP Perf bot in the morejs page cycler. Along with turning XP Perf red, the perf regression system notified me via email (forwarded below). The page load regression is about 30ms. There's a similar regression in the moz page cycler. Here's a link to the XP Perf dashboard to see the morejs regression: http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50 The interesting revisions between r27704 and r27710 are: r27705 - darin - Move various methods from glue to api.http://src.chromium.org/viewvc/chrome?view=revrevision=27705 r27708 - jar - Set JEMalloc as the default allocator (instead of TCMalloc). http://src.chromium.org/viewvc/chrome?view=revrevision=27708 r27710 - thestig - Disable CheckSvnModifiedDirectories for now.http://src.chromium.org/viewvc/chrome?view=revrevision=27710 @jar: Not meaning to pick on you, but my guess is the JEMalloc change is the cause. Did you expect a page load regression from your change? PS If you haven't heard of this perf regression system, don't worry -- it's a new tool in Chromium's toolbox. Email and docs describing it will be sent soon. Thanks, Chase -- Forwarded message -- From: build...@chromium.org Date: Thu, Oct 1, 2009 at 7:15 AM Subject: buildbot failure in Chromium on XP Perf, revision 27719 To: c...@google.com http://build.chromium.org/buildbot/waterfall/ Perf alert on XP Perf: page_cycler_morejs http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414 Revision: 27719 Blame list: ida...@google.com XP Perf Build 9414http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414 svnkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell/logs/stdio update scripts stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_2/logs/stdio taskkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_3/logs/stdio update stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/gclient/logs/stdio extract build stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/extract%20build/logs/stdio Start Crash Handler stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/Start%20Crash%20Handler/logs/stdio uploading perf_expectations.json page_cycler_moz IO_b_b: 41.8k (39.7k) IO_b_b_extcs1: 41.8k IO_b_r: 6.74k (6.0k) IO_b_r_extcs1: 6.62k IO_op_b: 51.6k (51.8k) IO_op_b_extcs1: 55.0k IO_op_r: 25.3k (28.3k) IO_op_r_extcs1: 25.2k t: 1.08k (1.19k) t_extcs1: 1.25k vm_pk_b: 8.24M (17.0M) vm_pk_b_extcs1: 9.68M vm_pk_r: 83.2M (72.9M) vm_pk_r_extcs1: 85.6M ws_pk_b: 20.0M (24.8M) ws_pk_b_extcs1: 21.4M ws_pk_r: 75.3M (73.7M) ws_pk_r_extcs1: 80.5M stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_moz/logs/stdio [resultshttp://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=150 ] page_cycler_morejs PERF_REGRESS: times/t IO_b_b: 19.2k (17.5k) IO_b_b_extcs1: 19.3k IO_b_r: 475 (243) IO_b_r_extcs1: 475 IO_op_b: 20.3k (19.5k) IO_op_b_extcs1: 23.4k IO_op_r: 9.56k (4.17k) IO_op_r_extcs1: 9.56k t: 1.4k (1.31k) t_extcs1: 1.44k vm_pk_b: 7.06M (16.1M) vm_pk_b_extcs1: 8.49M vm_pk_r: 8.28M (18.0M) vm_pk_r_extcs1: 8.3M ws_pk_b: 19.0M (23.8M) ws_pk_b_extcs1: 20.4M ws_pk_r: 12.6M (21.6M) ws_pk_r_extcs1: 12.6M stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_morejs/logs/stdio [resultshttp://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=150 ] Changed by: *ida...@google.com* Changed at: *Thu 01 Oct 2009 07:00:09* Branch: *src* Revision: *27719* Changed files: - *chrome/browser/privacy_blacklist/blocked_response.cc* - *chrome/browser/privacy_blacklist/blocked_response.h* - *chrome/browser/resources/privacy_blacklist_block.html* - *chrome/browser/renderer_host/resource_dispatcher_host.cc* - *chrome/browser/renderer_host/resource_dispatcher_host.h* Comments: Privacy Blacklist Unblock Summary --- Mostly implemented the unblocking for visual resources for the Privacy Blacklist. Merging now before I leave. Eveything here only has effect if the --privacy-blacklist flag specifies a Privacy Blacklist. Detailed Changes [chrome/browser/resources/privacy_blacklist.html] - Replaced the about:blank place-holder with variable to set the unblock link. - Open the Privacy Blacklist provider page in a new tab. This works around an issue where such request for a full-page (rather than a
[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers
Probably caused by jemalloc. Jim was experimenting with the idea of getting some dev-channel data from using jemalloc as opposed to tcmalloc. I'm not surprised there was a perf delta, but I am surprised by how much. The DOM benchmark in this test dropped by 8%. Several other benchmarks took similar hits. http://build.chromium.org/buildbot/perf/vista-release-dual-core/dom_perf/report.html?history=150 http://build.chromium.org/buildbot/perf/xp-release-single-core/bloat-http/report.html?history=150 But the memory test does use about 10% less RAM with jemalloc (as predicted): http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150 And almost all memory tests got better: http://build.chromium.org/buildbot/perf/dashboard/overview.html?graph=vm_peak_b So: tcmalloc == faster; jemalloc == smaller. We knew this. I think we should probably back out jemalloc - the perf hit is non-trivial, and the memory we can improve with other, upcoming tcmalloc work. Jim - how badly do you want jemalloc dev-channel data? I'm not sure it will buy us a lot other than what we already know. Mike On Thu, Oct 1, 2009 at 8:29 AM, Darin Fisher da...@chromium.org wrote: Note: my change was reverted for other reasons.-Darin On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.org wrote: Hey everyone, A performance regression has appeared on the XP Perf bot in the morejs page cycler. Along with turning XP Perf red, the perf regression system notified me via email (forwarded below). The page load regression is about 30ms. There's a similar regression in the moz page cycler. Here's a link to the XP Perf dashboard to see the morejs regression: http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50 The interesting revisions between r27704 and r27710 are: r27705 - darin - Move various methods from glue to api.http://src.chromium.org/viewvc/chrome?view=revrevision=27705 r27708 - jar - Set JEMalloc as the default allocator (instead of TCMalloc).http://src.chromium.org/viewvc/chrome?view=revrevision=27708 r27710 - thestig - Disable CheckSvnModifiedDirectories for now.http://src.chromium.org/viewvc/chrome?view=revrevision=27710 @jar: Not meaning to pick on you, but my guess is the JEMalloc change is the cause. Did you expect a page load regression from your change? PS If you haven't heard of this perf regression system, don't worry -- it's a new tool in Chromium's toolbox. Email and docs describing it will be sent soon. Thanks, Chase -- Forwarded message -- From: build...@chromium.org Date: Thu, Oct 1, 2009 at 7:15 AM Subject: buildbot failure in Chromium on XP Perf, revision 27719 To: c...@google.com http://build.chromium.org/buildbot/waterfall/ Perf alert on XP Perf: page_cycler_morejs http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414 Revision: 27719 Blame list: ida...@google.com XP Perf Build 9414http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414 svnkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell/logs/stdio update scripts stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_2/logs/stdio taskkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_3/logs/stdio update stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/gclient/logs/stdio extract build stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/extract%20build/logs/stdio Start Crash Handler stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/Start%20Crash%20Handler/logs/stdio uploading perf_expectations.json page_cycler_moz IO_b_b: 41.8k (39.7k) IO_b_b_extcs1: 41.8k IO_b_r: 6.74k (6.0k) IO_b_r_extcs1: 6.62k IO_op_b: 51.6k (51.8k) IO_op_b_extcs1: 55.0k IO_op_r: 25.3k (28.3k) IO_op_r_extcs1: 25.2k t: 1.08k (1.19k) t_extcs1: 1.25k vm_pk_b: 8.24M (17.0M) vm_pk_b_extcs1: 9.68M vm_pk_r: 83.2M (72.9M) vm_pk_r_extcs1: 85.6M ws_pk_b: 20.0M (24.8M) ws_pk_b_extcs1: 21.4M ws_pk_r: 75.3M (73.7M) ws_pk_r_extcs1: 80.5M stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_moz/logs/stdio [resultshttp://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=150 ] page_cycler_morejs PERF_REGRESS: times/t IO_b_b: 19.2k (17.5k) IO_b_b_extcs1: 19.3k IO_b_r: 475 (243) IO_b_r_extcs1: 475 IO_op_b: 20.3k (19.5k) IO_op_b_extcs1: 23.4k IO_op_r: 9.56k (4.17k) IO_op_r_extcs1: 9.56k t: 1.4k (1.31k) t_extcs1: 1.44k vm_pk_b: 7.06M (16.1M) vm_pk_b_extcs1: 8.49M vm_pk_r: 8.28M (18.0M) vm_pk_r_extcs1: 8.3M ws_pk_b: 19.0M (23.8M) ws_pk_b_extcs1: 20.4M ws_pk_r: 12.6M (21.6M) ws_pk_r_extcs1: 12.6M
[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers
I'm quite sure it is jemalloc. I failed miserably by not over-communicating this checkin. My apologies to all that I have inconvenience. We have just this week identified a number of misteps in our use of TCMalloc. I think that we can eventually reach an excellent result with TCMalloc... and we had a few fixes... but we also wanted to be able to talk more precisely about how things contrast with jemalloc (as folks ask us why we're looking so intently at tcmalloc). If folks are cool with it, it might be interesting to push the dev build with this in place. JEMalloc appears to be very conservative in its memory usage, but doesn't get the speed we've seen with TCMalloc. We can already see some specific areas where the current (checked in) incarnation of TCMalloc stumbles (example: today, TCMalloc never decommits memory in the browser process... yeah... that's just a bug... but I was wondering how much it hurt... and a switch to jemalloc would instantly provide a temporary fix). It may be interesting to see the response on the dev channel to this temporary change. Side benefits include some feedback on crashers, as each allocator illuminates a different set of corruption problems (if we have any :-) ). Do other folks agree it would be interesting to see a dev build go out with this in place?? Thanks, Jim On Thu, Oct 1, 2009 at 8:46 AM, Mike Belshe mbel...@google.com wrote: Probably caused by jemalloc. Jim was experimenting with the idea of getting some dev-channel data from using jemalloc as opposed to tcmalloc. I'm not surprised there was a perf delta, but I am surprised by how much. The DOM benchmark in this test dropped by 8%. Several other benchmarks took similar hits. http://build.chromium.org/buildbot/perf/vista-release-dual-core/dom_perf/report.html?history=150 http://build.chromium.org/buildbot/perf/xp-release-single-core/bloat-http/report.html?history=150 But the memory test does use about 10% less RAM with jemalloc (as predicted): http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150 And almost all memory tests got better: http://build.chromium.org/buildbot/perf/dashboard/overview.html?graph=vm_peak_b So: tcmalloc == faster; jemalloc == smaller. We knew this. I think we should probably back out jemalloc - the perf hit is non-trivial, and the memory we can improve with other, upcoming tcmalloc work. Jim - how badly do you want jemalloc dev-channel data? I'm not sure it will buy us a lot other than what we already know. Mike On Thu, Oct 1, 2009 at 8:29 AM, Darin Fisher da...@chromium.org wrote: Note: my change was reverted for other reasons.-Darin On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.orgwrote: Hey everyone, A performance regression has appeared on the XP Perf bot in the morejs page cycler. Along with turning XP Perf red, the perf regression system notified me via email (forwarded below). The page load regression is about 30ms. There's a similar regression in the moz page cycler. Here's a link to the XP Perf dashboard to see the morejs regression: http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50 The interesting revisions between r27704 and r27710 are: r27705 - darin - Move various methods from glue to api.http://src.chromium.org/viewvc/chrome?view=revrevision=27705 r27708 - jar - Set JEMalloc as the default allocator (instead of TCMalloc).http://src.chromium.org/viewvc/chrome?view=revrevision=27708 r27710 - thestig - Disable CheckSvnModifiedDirectories for now.http://src.chromium.org/viewvc/chrome?view=revrevision=27710 @jar: Not meaning to pick on you, but my guess is the JEMalloc change is the cause. Did you expect a page load regression from your change? PS If you haven't heard of this perf regression system, don't worry -- it's a new tool in Chromium's toolbox. Email and docs describing it will be sent soon. Thanks, Chase -- Forwarded message -- From: build...@chromium.org Date: Thu, Oct 1, 2009 at 7:15 AM Subject: buildbot failure in Chromium on XP Perf, revision 27719 To: c...@google.com http://build.chromium.org/buildbot/waterfall/ Perf alert on XP Perf: page_cycler_morejs http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414 Revision: 27719 Blame list: ida...@google.com XP Perf Build 9414http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414 svnkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell/logs/stdio update scripts stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_2/logs/stdio taskkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_3/logs/stdio update stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/gclient/logs/stdio
[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers
I think we should be willing to take a temporary performance hit on the dev channel in the interests of generating data which will eventually improve stability. Could we set jemalloc on selected renderer processes? I realize that wouldn't necessarily only impact the target domains, but it might be better than making the change global. -scott On Thu, Oct 1, 2009 at 10:47 AM, Jim Roskind j...@chromium.org wrote: I'm quite sure it is jemalloc. I failed miserably by not over-communicating this checkin. My apologies to all that I have inconvenience. We have just this week identified a number of misteps in our use of TCMalloc. I think that we can eventually reach an excellent result with TCMalloc... and we had a few fixes... but we also wanted to be able to talk more precisely about how things contrast with jemalloc (as folks ask us why we're looking so intently at tcmalloc). If folks are cool with it, it might be interesting to push the dev build with this in place. JEMalloc appears to be very conservative in its memory usage, but doesn't get the speed we've seen with TCMalloc. We can already see some specific areas where the current (checked in) incarnation of TCMalloc stumbles (example: today, TCMalloc never decommits memory in the browser process... yeah... that's just a bug... but I was wondering how much it hurt... and a switch to jemalloc would instantly provide a temporary fix). It may be interesting to see the response on the dev channel to this temporary change. Side benefits include some feedback on crashers, as each allocator illuminates a different set of corruption problems (if we have any :-) ). Do other folks agree it would be interesting to see a dev build go out with this in place?? Thanks, Jim On Thu, Oct 1, 2009 at 8:46 AM, Mike Belshe mbel...@google.com wrote: Probably caused by jemalloc. Jim was experimenting with the idea of getting some dev-channel data from using jemalloc as opposed to tcmalloc. I'm not surprised there was a perf delta, but I am surprised by how much. The DOM benchmark in this test dropped by 8%. Several other benchmarks took similar hits. http://build.chromium.org/buildbot/perf/vista-release-dual-core/dom_perf/report.html?history=150 http://build.chromium.org/buildbot/perf/xp-release-single-core/bloat-http/report.html?history=150 But the memory test does use about 10% less RAM with jemalloc (as predicted): http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150 And almost all memory tests got better: http://build.chromium.org/buildbot/perf/dashboard/overview.html?graph=vm_peak_b So: tcmalloc == faster; jemalloc == smaller. We knew this. I think we should probably back out jemalloc - the perf hit is non-trivial, and the memory we can improve with other, upcoming tcmalloc work. Jim - how badly do you want jemalloc dev-channel data? I'm not sure it will buy us a lot other than what we already know. Mike On Thu, Oct 1, 2009 at 8:29 AM, Darin Fisher da...@chromium.org wrote: Note: my change was reverted for other reasons.-Darin On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.orgwrote: Hey everyone, A performance regression has appeared on the XP Perf bot in the morejs page cycler. Along with turning XP Perf red, the perf regression system notified me via email (forwarded below). The page load regression is about 30ms. There's a similar regression in the moz page cycler. Here's a link to the XP Perf dashboard to see the morejs regression: http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50 The interesting revisions between r27704 and r27710 are: r27705 - darin - Move various methods from glue to api.http://src.chromium.org/viewvc/chrome?view=revrevision=27705 r27708 - jar - Set JEMalloc as the default allocator (instead of TCMalloc).http://src.chromium.org/viewvc/chrome?view=revrevision=27708 r27710 - thestig - Disable CheckSvnModifiedDirectories for now.http://src.chromium.org/viewvc/chrome?view=revrevision=27710 @jar: Not meaning to pick on you, but my guess is the JEMalloc change is the cause. Did you expect a page load regression from your change? PS If you haven't heard of this perf regression system, don't worry -- it's a new tool in Chromium's toolbox. Email and docs describing it will be sent soon. Thanks, Chase -- Forwarded message -- From: build...@chromium.org Date: Thu, Oct 1, 2009 at 7:15 AM Subject: buildbot failure in Chromium on XP Perf, revision 27719 To: c...@google.com http://build.chromium.org/buildbot/waterfall/ Perf alert on XP Perf: page_cycler_morejs http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414 Revision: 27719 Blame list: ida...@google.com XP Perf Build 9414http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414 svnkill
[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers
On Thu, Oct 1, 2009 at 11:27 AM, Scott Hess sh...@chromium.org wrote: I think we should be willing to take a temporary performance hit on the dev channel in the interests of generating data which will eventually improve stability. Could we set jemalloc on selected renderer processes? I realize that wouldn't necessarily only impact the target domains, but it might be better than making the change global. It can be set by a per-process environment variable. So... yes, this could be done. Mix-and-match allocators might be a little strange for anything other than debugging/testing. Mike -scott On Thu, Oct 1, 2009 at 10:47 AM, Jim Roskind j...@chromium.org wrote: I'm quite sure it is jemalloc. I failed miserably by not over-communicating this checkin. My apologies to all that I have inconvenience. We have just this week identified a number of misteps in our use of TCMalloc. I think that we can eventually reach an excellent result with TCMalloc... and we had a few fixes... but we also wanted to be able to talk more precisely about how things contrast with jemalloc (as folks ask us why we're looking so intently at tcmalloc). If folks are cool with it, it might be interesting to push the dev build with this in place. JEMalloc appears to be very conservative in its memory usage, but doesn't get the speed we've seen with TCMalloc. We can already see some specific areas where the current (checked in) incarnation of TCMalloc stumbles (example: today, TCMalloc never decommits memory in the browser process... yeah... that's just a bug... but I was wondering how much it hurt... and a switch to jemalloc would instantly provide a temporary fix). It may be interesting to see the response on the dev channel to this temporary change. Side benefits include some feedback on crashers, as each allocator illuminates a different set of corruption problems (if we have any :-) ). Do other folks agree it would be interesting to see a dev build go out with this in place?? Thanks, Jim On Thu, Oct 1, 2009 at 8:46 AM, Mike Belshe mbel...@google.com wrote: Probably caused by jemalloc. Jim was experimenting with the idea of getting some dev-channel data from using jemalloc as opposed to tcmalloc. I'm not surprised there was a perf delta, but I am surprised by how much. The DOM benchmark in this test dropped by 8%. Several other benchmarks took similar hits. http://build.chromium.org/buildbot/perf/vista-release-dual-core/dom_perf/report.html?history=150 http://build.chromium.org/buildbot/perf/xp-release-single-core/bloat-http/report.html?history=150 But the memory test does use about 10% less RAM with jemalloc (as predicted): http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150 And almost all memory tests got better: http://build.chromium.org/buildbot/perf/dashboard/overview.html?graph=vm_peak_b So: tcmalloc == faster; jemalloc == smaller. We knew this. I think we should probably back out jemalloc - the perf hit is non-trivial, and the memory we can improve with other, upcoming tcmalloc work. Jim - how badly do you want jemalloc dev-channel data? I'm not sure it will buy us a lot other than what we already know. Mike On Thu, Oct 1, 2009 at 8:29 AM, Darin Fisher da...@chromium.org wrote: Note: my change was reverted for other reasons.-Darin On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.orgwrote: Hey everyone, A performance regression has appeared on the XP Perf bot in the morejs page cycler. Along with turning XP Perf red, the perf regression system notified me via email (forwarded below). The page load regression is about 30ms. There's a similar regression in the moz page cycler. Here's a link to the XP Perf dashboard to see the morejs regression: http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50 The interesting revisions between r27704 and r27710 are: r27705 - darin - Move various methods from glue to api.http://src.chromium.org/viewvc/chrome?view=revrevision=27705 r27708 - jar - Set JEMalloc as the default allocator (instead of TCMalloc).http://src.chromium.org/viewvc/chrome?view=revrevision=27708 r27710 - thestig - Disable CheckSvnModifiedDirectories for now.http://src.chromium.org/viewvc/chrome?view=revrevision=27710 @jar: Not meaning to pick on you, but my guess is the JEMalloc change is the cause. Did you expect a page load regression from your change? PS If you haven't heard of this perf regression system, don't worry -- it's a new tool in Chromium's toolbox. Email and docs describing it will be sent soon. Thanks, Chase -- Forwarded message -- From: build...@chromium.org Date: Thu, Oct 1, 2009 at 7:15 AM Subject: buildbot failure in Chromium on XP Perf, revision 27719 To: c...@google.com http://build.chromium.org/buildbot/waterfall/ Perf alert on XP Perf:
[chromium-dev] Re: XP Perf page load regression on morejs and moz page cyclers
On Thu, Oct 1, 2009 at 11:32 AM, Mike Belshe mbel...@google.com wrote: On Thu, Oct 1, 2009 at 11:27 AM, Scott Hess sh...@chromium.org wrote: Could we set jemalloc on selected renderer processes? I realize that wouldn't necessarily only impact the target domains, but it might be better than making the change global. It can be set by a per-process environment variable. So... yes, this could be done. Mix-and-match allocators might be a little strange for anything other than debugging/testing. I was thinking enabling for the gmail renderer (and whoever gets stuck in that process) might be more useful than enabling for everyone - but obviously we'd need ways to identify the source of any uploaded data. That said, being able to enable alternate malloc libraries in the browser process might have relatively low performance costs compared to the value of the data generated. I don't mean to imply that browser-process performance is not important, but rather that race conditions and double-frees and the like are much more dangerous there. Also, interpreting the data would probably be easier (renderer data and browser results would be internally consistent). -scott --~--~-~--~~~---~--~~ 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: XP Perf page load regression on morejs and moz page cyclers
On Thu, Oct 1, 2009 at 12:38 PM, Scott Hess sh...@chromium.org wrote: On Thu, Oct 1, 2009 at 11:32 AM, Mike Belshe mbel...@google.com wrote: On Thu, Oct 1, 2009 at 11:27 AM, Scott Hess sh...@chromium.org wrote: Could we set jemalloc on selected renderer processes? I realize that wouldn't necessarily only impact the target domains, but it might be better than making the change global. It can be set by a per-process environment variable. So... yes, this could be done. Mix-and-match allocators might be a little strange for anything other than debugging/testing. I was thinking enabling for the gmail renderer (and whoever gets stuck in that process) might be more useful than enabling for everyone - but obviously we'd need ways to identify the source of any uploaded data. That said, being able to enable alternate malloc libraries in the browser process might have relatively low performance costs compared to the value of the data generated. I don't mean to imply that browser-process performance is not important, but rather that race conditions and double-frees and the like are much more dangerous there. Also, interpreting the data would probably be easier (renderer data and browser results would be internally consistent). Both of these points seem like big wins to me, for what it's worth. --~--~-~--~~~---~--~~ 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: XP Perf page load regression on morejs and moz page cyclers
Thanks Darin, Mike, and Jim for the quick response. Sounds like we'll have this in the trunk for a couple days at least if not longer, so I updated the XP perf expectation. The builder should stay green for now. On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips ch...@chromium.org wrote: Hey everyone, A performance regression has appeared on the XP Perf bot in the morejs page cycler. Along with turning XP Perf red, the perf regression system notified me via email (forwarded below). The page load regression is about 30ms. There's a similar regression in the moz page cycler. Here's a link to the XP Perf dashboard to see the morejs regression: http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50 The interesting revisions between r27704 and r27710 are: r27705 - darin - Move various methods from glue to api.http://src.chromium.org/viewvc/chrome?view=revrevision=27705 r27708 - jar - Set JEMalloc as the default allocator (instead of TCMalloc). http://src.chromium.org/viewvc/chrome?view=revrevision=27708 r27710 - thestig - Disable CheckSvnModifiedDirectories for now.http://src.chromium.org/viewvc/chrome?view=revrevision=27710 @jar: Not meaning to pick on you, but my guess is the JEMalloc change is the cause. Did you expect a page load regression from your change? PS If you haven't heard of this perf regression system, don't worry -- it's a new tool in Chromium's toolbox. Email and docs describing it will be sent soon. Thanks, Chase -- Forwarded message -- From: build...@chromium.org Date: Thu, Oct 1, 2009 at 7:15 AM Subject: buildbot failure in Chromium on XP Perf, revision 27719 To: c...@google.com http://build.chromium.org/buildbot/waterfall/ Perf alert on XP Perf: page_cycler_morejs http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414 Revision: 27719 Blame list: ida...@google.com XP Perf Build 9414http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414 svnkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell/logs/stdio update scripts stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_2/logs/stdio taskkill stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_3/logs/stdio update stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/gclient/logs/stdio extract build stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/extract%20build/logs/stdio Start Crash Handler stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/Start%20Crash%20Handler/logs/stdio uploading perf_expectations.json page_cycler_moz IO_b_b: 41.8k (39.7k) IO_b_b_extcs1: 41.8k IO_b_r: 6.74k (6.0k) IO_b_r_extcs1: 6.62k IO_op_b: 51.6k (51.8k) IO_op_b_extcs1: 55.0k IO_op_r: 25.3k (28.3k) IO_op_r_extcs1: 25.2k t: 1.08k (1.19k) t_extcs1: 1.25k vm_pk_b: 8.24M (17.0M) vm_pk_b_extcs1: 9.68M vm_pk_r: 83.2M (72.9M) vm_pk_r_extcs1: 85.6M ws_pk_b: 20.0M (24.8M) ws_pk_b_extcs1: 21.4M ws_pk_r: 75.3M (73.7M) ws_pk_r_extcs1: 80.5M stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_moz/logs/stdio [resultshttp://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=150 ] page_cycler_morejs PERF_REGRESS: times/t IO_b_b: 19.2k (17.5k) IO_b_b_extcs1: 19.3k IO_b_r: 475 (243) IO_b_r_extcs1: 475 IO_op_b: 20.3k (19.5k) IO_op_b_extcs1: 23.4k IO_op_r: 9.56k (4.17k) IO_op_r_extcs1: 9.56k t: 1.4k (1.31k) t_extcs1: 1.44k vm_pk_b: 7.06M (16.1M) vm_pk_b_extcs1: 8.49M vm_pk_r: 8.28M (18.0M) vm_pk_r_extcs1: 8.3M ws_pk_b: 19.0M (23.8M) ws_pk_b_extcs1: 20.4M ws_pk_r: 12.6M (21.6M) ws_pk_r_extcs1: 12.6M stdiohttp://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_morejs/logs/stdio [resultshttp://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=150 ] Changed by: *ida...@google.com* Changed at: *Thu 01 Oct 2009 07:00:09* Branch: *src* Revision: *27719* Changed files: - *chrome/browser/privacy_blacklist/blocked_response.cc* - *chrome/browser/privacy_blacklist/blocked_response.h* - *chrome/browser/resources/privacy_blacklist_block.html* - *chrome/browser/renderer_host/resource_dispatcher_host.cc* - *chrome/browser/renderer_host/resource_dispatcher_host.h* Comments: Privacy Blacklist Unblock Summary --- Mostly implemented the unblocking for visual resources for the Privacy Blacklist. Merging now before I leave. Eveything here only has effect if the --privacy-blacklist flag specifies a Privacy Blacklist. Detailed Changes [chrome/browser/resources/privacy_blacklist.html] - Replaced the about:blank place-holder with variable to set
