Remove a stray setReserve that causes dynamic allocation in picture creation.

Remove a stray setReserve that causes dynamic allocation in picture creation.

This brings us down to about 10 calls to malloc per picture.

No measurable change in bench_record or bench_pictures.

BUG=

Committed: http://code.google.com/p/skia/source/detail?r=13136

[reed1, 2014-01-21 19:07:09]

Hmmm, are we just delaying the cost of creating this? Do we sometimes never need
the "reserve", and so we shouldn't allocate it now?

[mtklein, 2014-01-21 19:16:46]

On 2014/01/21 19:07:09, reed1 wrote:
> Hmmm, are we just delaying the cost of creating this? Do we sometimes never
need
> the "reserve", and so we shouldn't allocate it now?

Yeah, this delays the first allocation to the first save() call.  Here we're
assuming we'll get down ~32 nested saves for the reserve to fully pay off. 
Getting that deep gets less and less likely as pictures get smaller.

I'd be surprised if this matters much, either in initial creation cost or in
recording speed.  It's just 128 low hanging bytes that are easy to make lazy. 
If nothing else it eliminates uninteresting noise.

[reed1, 2014-01-21 19:23:16]

lgtm

perhaps my earlier question points to this one: what should the first
growth-alloc call be, given expected maximum depth (which we can statistically
measure I presume)?

[mtklein, 2014-01-21 19:57:01]

On 2014/01/21 19:23:16, reed1 wrote:
> lgtm
> 
> perhaps my earlier question points to this one: what should the first
> growth-alloc call be, given expected maximum depth (which we can statistically
> measure I presume)?

This is a really good question.  My rule of thumb is to not make any reservation
call you're not sure about.

We already have several disagreeing answers for this even when we assume we know
nothing about the distribution of maximum depths:
  - std::vector grows by 2x
  - SkTDArray grows by 1.25(x+4)
  - SkTArray by 1.5x
  - std::deque grows by 4K or by 16 items, whichever's larger
  - SkDeque grows by 1 item

We certainly can go gather the distribution of maximum depths over all our SKPs,
and from there we can either pick a single
growth rate or even determine a custom fixed growth schedule use-by-use.  Even
then there's still a degree of freedom left 
here, which is how we decide to trade off unused allocated space vs. time spent
reallocating (or splitting into 
non-contiguous chunks).

This is labor intensive.  What I'd propose is to blow away as many of these
guesses as possible, pick one of these data
structures to use as much as possible (I like SkTDArray), watch for problems in
a profile, and tune then.  If then we find
two parts of the code pulling us toward different growth rates, we can
parameterize it after the fact.

This is all entirely ignoring any knowledge we have of the individual size
distributions.  Sometimes it's just as well to ignore
it as to exploit it.  If we find ourselves unable to ignore certain known sizes,
I'd like to pull out something like the
somewhat terrifyingly named SkSTDArray to get that allocation merged into the
parent.

[commit-bot: I haz the power, 2014-01-21 19:57:16]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/mtklein@google.com/132693009/1

[reed1, 2014-01-21 20:20:13]

On 2014/01/21 19:57:01, mtklein wrote:
> On 2014/01/21 19:23:16, reed1 wrote:
> > lgtm
> > 
> > perhaps my earlier question points to this one: what should the first
> > growth-alloc call be, given expected maximum depth (which we can
statistically
> > measure I presume)?
> 
> This is a really good question.  My rule of thumb is to not make any
reservation
> call you're not sure about.
> 
> We already have several disagreeing answers for this even when we assume we
know
> nothing about the distribution of maximum depths:
>   - std::vector grows by 2x
>   - SkTDArray grows by 1.25(x+4)
>   - SkTArray by 1.5x
>   - std::deque grows by 4K or by 16 items, whichever's larger
>   - SkDeque grows by 1 item
> 
> We certainly can go gather the distribution of maximum depths over all our
SKPs,
> and from there we can either pick a single
> growth rate or even determine a custom fixed growth schedule use-by-use.  Even
> then there's still a degree of freedom left 
> here, which is how we decide to trade off unused allocated space vs. time
spent
> reallocating (or splitting into 
> non-contiguous chunks).
> 
> This is labor intensive.  What I'd propose is to blow away as many of these
> guesses as possible, pick one of these data
> structures to use as much as possible (I like SkTDArray), watch for problems
in
> a profile, and tune then.  If then we find
> two parts of the code pulling us toward different growth rates, we can
> parameterize it after the fact.
> 
> This is all entirely ignoring any knowledge we have of the individual size
> distributions.  Sometimes it's just as well to ignore
> it as to exploit it.  If we find ourselves unable to ignore certain known
sizes,
> I'd like to pull out something like the
> somewhat terrifyingly named SkSTDArray to get that allocation merged into the
> parent.

Let the record show that SkDeque is runtime-configurable as to how much it
allocates when it has to grow. The default is 1.

[commit-bot: I haz the power, 2014-01-21 20:48:48]

Change committed as 13136

[mtklein, 2014-01-21 20:50:17]

On 2014/01/21 20:20:13, reed1 wrote:
> On 2014/01/21 19:57:01, mtklein wrote:
> > On 2014/01/21 19:23:16, reed1 wrote:
> > > lgtm
> > > 
> > > perhaps my earlier question points to this one: what should the first
> > > growth-alloc call be, given expected maximum depth (which we can
> statistically
> > > measure I presume)?
> > 
> > This is a really good question.  My rule of thumb is to not make any
> reservation
> > call you're not sure about.
> > 
> > We already have several disagreeing answers for this even when we assume we
> know
> > nothing about the distribution of maximum depths:
> >   - std::vector grows by 2x
> >   - SkTDArray grows by 1.25(x+4)
> >   - SkTArray by 1.5x
> >   - std::deque grows by 4K or by 16 items, whichever's larger
> >   - SkDeque grows by 1 item
> > 
> > We certainly can go gather the distribution of maximum depths over all our
> SKPs,
> > and from there we can either pick a single
> > growth rate or even determine a custom fixed growth schedule use-by-use. 
Even
> > then there's still a degree of freedom left 
> > here, which is how we decide to trade off unused allocated space vs. time
> spent
> > reallocating (or splitting into 
> > non-contiguous chunks).
> > 
> > This is labor intensive.  What I'd propose is to blow away as many of these
> > guesses as possible, pick one of these data
> > structures to use as much as possible (I like SkTDArray), watch for problems
> in
> > a profile, and tune then.  If then we find
> > two parts of the code pulling us toward different growth rates, we can
> > parameterize it after the fact.
> > 
> > This is all entirely ignoring any knowledge we have of the individual size
> > distributions.  Sometimes it's just as well to ignore
> > it as to exploit it.  If we find ourselves unable to ignore certain known
> sizes,
> > I'd like to pull out something like the
> > somewhat terrifyingly named SkSTDArray to get that allocation merged into
the
> > parent.
> 
> Let the record show that SkDeque is runtime-configurable as to how much it
> allocates when it has to grow. The default is 1.

Right, yep, I am remiss.  It's used in plenty of places with N>1.