allocate memory manually in SkLiteDL

allocate memory manually in SkLiteDL

Instead of growing at SkTDArray's chosen rate (+4, then *1.25),
grow in additive 4K pages.  This is my attempt to make realloc()
have the best chance of not copying and to keep fragmentation down.
Because we use a freelist the rate we grow doesn't affect performance
too much.

I'm not getting very reliable numbers, but this looks maybe 5-10% faster
for recording, mainly I think from inlining the allocation fast path into
push().

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2231553002

Committed: https://skia.googlesource.com/skia/+/b20283357a09300353dd62962086f3791161e3b8

[mtklein_C, 2016-08-09 20:42:47]

Description was changed from

==========
allocate memory manually in SkLiteDL

Instead of growing at SkTDArray's chosen rate (+4, then *1.25),
grow in additive 4K pages.  This is my attempt to make realloc()
have the best chance of not copying and to keep fragmentation down.
Because we use a freelist the rate we grow doesn't affect performance
too much.

I'm not getting very reliable numbers, but this looks maybe 5-10% faster
for recording, mainly I think by inlining the allocation fast path into
push() (and push in turn into each Op's constructor).

BUG=skia:
==========

to

==========
allocate memory manually in SkLiteDL

Instead of growing at SkTDArray's chosen rate (+4, then *1.25),
grow in additive 4K pages.  This is my attempt to make realloc()
have the best chance of not copying and to keep fragmentation down.
Because we use a freelist the rate we grow doesn't affect performance
too much.

I'm not getting very reliable numbers, but this looks maybe 5-10% faster
for recording, mainly I think by inlining the allocation fast path into
push() (and push in turn into each Op's constructor).

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2231553002
==========

[mtklein_C, 2016-08-09 20:46:06]

Description was changed from

==========
allocate memory manually in SkLiteDL

Instead of growing at SkTDArray's chosen rate (+4, then *1.25),
grow in additive 4K pages.  This is my attempt to make realloc()
have the best chance of not copying and to keep fragmentation down.
Because we use a freelist the rate we grow doesn't affect performance
too much.

I'm not getting very reliable numbers, but this looks maybe 5-10% faster
for recording, mainly I think by inlining the allocation fast path into
push() (and push in turn into each Op's constructor).

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2231553002
==========

to

==========
allocate memory manually in SkLiteDL

Instead of growing at SkTDArray's chosen rate (+4, then *1.25),
grow in additive 4K pages.  This is my attempt to make realloc()
have the best chance of not copying and to keep fragmentation down.
Because we use a freelist the rate we grow doesn't affect performance
too much.

I'm not getting very reliable numbers, but this looks maybe 5-10% faster
for recording, mainly I think from inlining the allocation fast path into
push().

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2231553002
==========

[mtklein_C, 2016-08-09 20:56:43]

The CQ bit was checked by mtklein@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-09 20:56:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-09 21:19:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-09 21:19:07]

Dry run: This issue passed the CQ dry run.

[mtklein_C, 2016-08-09 21:36:42]

mtklein@chromium.org changed reviewers:
+ herb@google.com, reed@google.com

[mtklein, 2016-08-09 22:12:21]

mtklein@google.com changed reviewers:
+ mtklein@google.com

[mtklein, 2016-08-09 22:12:22]

The CQ bit was checked by mtklein@google.com

[mtklein, 2016-08-09 22:12:22]

lgtm

[commit-bot: I haz the power, 2016-08-09 22:12:25]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-09 22:13:20]

Description was changed from

==========
allocate memory manually in SkLiteDL

Instead of growing at SkTDArray's chosen rate (+4, then *1.25),
grow in additive 4K pages.  This is my attempt to make realloc()
have the best chance of not copying and to keep fragmentation down.
Because we use a freelist the rate we grow doesn't affect performance
too much.

I'm not getting very reliable numbers, but this looks maybe 5-10% faster
for recording, mainly I think from inlining the allocation fast path into
push().

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2231553002
==========

to

==========
allocate memory manually in SkLiteDL

Instead of growing at SkTDArray's chosen rate (+4, then *1.25),
grow in additive 4K pages.  This is my attempt to make realloc()
have the best chance of not copying and to keep fragmentation down.
Because we use a freelist the rate we grow doesn't affect performance
too much.

I'm not getting very reliable numbers, but this looks maybe 5-10% faster
for recording, mainly I think from inlining the allocation fast path into
push().

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2231553002

Committed:
https://skia.googlesource.com/skia/+/b20283357a09300353dd62962086f3791161e3b8
==========

[commit-bot: I haz the power, 2016-08-09 22:13:21]

Committed patchset #2 (id:20001) as
https://skia.googlesource.com/skia/+/b20283357a09300353dd62962086f3791161e3b8

[reed1, 2016-08-10 12:01:47]

if you're right, and most of the gain is from inlining, perhaps we should try
that same technique on SkTDArray itself, to try to speed it up too.

[mtklein, 2016-08-10 13:18:58]

On 2016/08/10 12:01:47, reed1 wrote:
> if you're right, and most of the gain is from inlining, perhaps we should try
> that same technique on SkTDArray itself, to try to speed it up too.

agreed

[mtklein, 2016-08-10 14:32:12]

On 2016/08/10 13:18:58, mtklein wrote:
> On 2016/08/10 12:01:47, reed1 wrote:
> > if you're right, and most of the gain is from inlining, perhaps we should
try
> > that same technique on SkTDArray itself, to try to speed it up too.
> 
> agreed

I took a quick look a this.  SkTDArray has too many methods that call into each
other to make this an easy task.  If it's important we can do it sometime, but
it's not trivial.