Enable TCMalloc doubly-linked freelist in release builds

Enable TCMalloc doubly-linked freelist in release buildsBUG=NoneTEST=None
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=105312

[jschuh, 2011-10-12 19:36:32]

As discussed, I'll check this in early tomorrow morning to get accurate stats on
performance impact.

[jschuh, 2011-10-13 00:16:41]

Done.

[jar (doing other things), 2011-10-13 00:18:29]

As per discussion, please land when the tree is pretty quiet, so we can see any
perf implications.

Thanks!

LGTM

[Tom Hudson, 2011-10-20 20:42:47]

Where was the discussion? Was there any perf test impact observed? I think I'm
seeing memory management overhead on Linux increase of 50% or more in my
profiles because of tcmalloc::FL_Next().

Looking at free_list.cc, I note that the if(foo){MEMORY_CHECK(bar)} calls aren't
debug-only; they're running in release builds. Was this intended? If I comment
out the consistency checks, FL_Next drops from 2nd on the profile (2.45%) to 
27th (0.46%), and tcmalloc drops below 1.5% of total CPU time. Unfortunately,
the page cycler tests I'm using to evaluate total performance are too noisy to
verify a visible change...

[jschuh, 2011-10-20 22:57:53]

Yes, this was the intent. We didn't observe a negative performance impact on the
perf bots. If you have hard numbers that point to significant performance
regression we'll look at how to address it. But given that this was done to
address a security deficiency, there'd need to be a serious impact on
performance before we'd consider rolling the CL out.

-j


On 2011/10/20 20:42:47, Tom Hudson wrote:
> Where was the discussion? Was there any perf test impact observed? I think I'm
> seeing memory management overhead on Linux increase of 50% or more in my
> profiles because of tcmalloc::FL_Next().
> 
> Looking at free_list.cc, I note that the if(foo){MEMORY_CHECK(bar)} calls
aren't
> debug-only; they're running in release builds. Was this intended? If I comment
> out the consistency checks, FL_Next drops from 2nd on the profile (2.45%) to 
> 27th (0.46%), and tcmalloc drops below 1.5% of total CPU time. Unfortunately,
> the page cycler tests I'm using to evaluate total performance are too noisy to
> verify a visible change...

[jar (doing other things), 2011-10-20 23:37:54]

Can you clarify what the percentage was of?

For instance, are you looking at browser perf, or renderer perf?

Were you measuring perf in the renderer when it was in a quiescent mode,
doing just about nothing, and detecting a 2.45% rise over the (nearly) zero
CPU usage?

When we run page cycler, we so no perf regression, so your report is a bit
confusing.

Thanks,

Jim

On Thu, Oct 20, 2011 at 1:42 PM, <tomhudson@chromium.org> wrote:

> Where was the discussion? Was there any perf test impact observed? I think
> I'm
> seeing memory management overhead on Linux increase of 50% or more in my
> profiles because of tcmalloc::FL_Next().
>
> Looking at free_list.cc, I note that the if(foo){MEMORY_CHECK(bar)} calls
> aren't
> debug-only; they're running in release builds. Was this intended? If I
> comment
> out the consistency checks, FL_Next drops from 2nd on the profile (2.45%)
> to
> 27th (0.46%), and tcmalloc drops below 1.5% of total CPU time.
> Unfortunately,
> the page cycler tests I'm using to evaluate total performance are too noisy
> to
> verify a visible change...
>
>
>
>
http://codereview.chromium.**org/8242017/<http://codereview.chromium.org/8242...
>