Oilpan: mark fast/forms/select/menulist-appearance-basic.html as slow (dbg)

Oilpan: mark fast/forms/select/menulist-appearance-basic.html as slow (dbg)

R=haraken@chromium.org
BUG=397425
NOTRY=true

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=178906

[sof, 2014-07-25 06:40:02]

Please take a look.

[haraken, 2014-07-25 06:49:18]

LGTM at the moment.

Now I understand the issue :) I think a right fix would be to avoid allocating
these short-lived objects on GC's heap. When Mads faced performance regression
of some editing tests, we tried to restructure code so that it doesn't allocate
a lot of short-lived objects to the heap
(https://codereview.chromium.org/330383004/). Though the CL hasn't yet landed.

In this particular case, would it be possible to restructure the code to avoid
allocating a lot of short-lived objects?

[sof, 2014-07-25 07:02:22]

On 2014/07/25 06:49:18, haraken wrote:
> LGTM at the moment.
> 
> Now I understand the issue :) I think a right fix would be to avoid allocating
> these short-lived objects on GC's heap. When Mads faced performance regression
> of some editing tests, we tried to restructure code so that it doesn't
allocate
> a lot of short-lived objects to the heap
> (https://codereview.chromium.org/330383004/). Though the CL hasn't yet landed.
> 
> In this particular case, would it be possible to restructure the code to avoid
> allocating a lot of short-lived objects?

It would involve off-heap collections (vector, in this case) holding Node*, so
not readily.

But, yes - taking advantage that this is a stack allocated object with no
reference escaping [reminds me of region-based allocation and types] could be
worth pushing on.

[sof, 2014-07-25 07:04:07]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2014-07-25 07:04:37]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/sigbjornf@opera.com/419193002/1

[haraken, 2014-07-25 07:15:56]

On 2014/07/25 07:02:22, sof wrote:
> On 2014/07/25 06:49:18, haraken wrote:
> > LGTM at the moment.
> > 
> > Now I understand the issue :) I think a right fix would be to avoid
allocating
> > these short-lived objects on GC's heap. When Mads faced performance
regression
> > of some editing tests, we tried to restructure code so that it doesn't
> allocate
> > a lot of short-lived objects to the heap
> > (https://codereview.chromium.org/330383004/). Though the CL hasn't yet
landed.
> > 
> > In this particular case, would it be possible to restructure the code to
avoid
> > allocating a lot of short-lived objects?
> 
> It would involve off-heap collections (vector, in this case) holding Node*, so
> not readily.
> 
> But, yes - taking advantage that this is a stack allocated object with no
> reference escaping [reminds me of region-based allocation and types] could be
> worth pushing on.

Yeah, as a short-term fix, we can just use an off-heap vector of raw pointers.
If there are more use cases where we need similar care, we'll need to implement
something like region-based allocation in oilpan's infrastructure. Erik@ and
Mad@ would have an opinion on this.

[commit-bot: I haz the power, 2014-07-25 08:01:44]

Change committed as 178906