Inspector: Store array of small numbers in 16 bit instead of 64 bit.

Inspector: Store array of small numbers in 16 bit instead of 64 bit.

Save 1.5 KB by storing small numbers in 16 bit instead of 64 bit. Minor change 
but should be smaller and faster.

         +3: blink::InspectorBackendDispatcher::commandName(blink::InspectorBackendDispatcher::MethodNames) type=t, (was 21 bytes, now 24 bytes)
      -1518: blink::InspectorBackendDispatcher::commandNamesIndex type=r, (was 2024 bytes, now 506 bytes)

R=yurys@chromium.org

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

[Daniel Bratell, 2015-02-26 16:16:36]

bratell@opera.com changed reviewers:
+ yurys@chromium.org

[Daniel Bratell, 2015-02-26 16:16:37]

Just a minor thing I noticed while taking a look at chromium footprint. Not
something I would normally care about but it was such a small and obvious
change.

The largest number today is ~6000 so there need to be ten times as many strings
before that assert will tell us things need tuning.

[yurys, 2015-02-27 09:55:58]

lgtm,

though the memory savings look negligible to me. I wonder how you spot this
particular place? Is it just a continuous static block that is longer than
others?

[Daniel Bratell, 2015-02-27 10:16:56]

On 2015/02/27 09:55:58, yurys wrote:
> lgtm,
> 
> though the memory savings look negligible to me. I wonder how you spot this
> particular place? Is it just a continuous static block that is longer than
> others?

This particular one I saw by scanning through the code trying to understand why
InspectorBackendDispatcher.cpp shrinks 40 KB with --fno-inline. I don't know of
any automated way of noticing these. Had it been padding or more obvious
allocated-but-never-read valgrind dhat would have worked (except that this is
below all kinds of thresholds I would set).

I've had some loose idea of compressing blocks of the binary and check which one
compress to almost nothing (a sign of redundant source or data) but I'm not sure
it would be worth the effort.

Why InspectorBackendDispatcher has a 40 KB size difference between inlining and
not inlining I don't know but it might have something to with the Callback
classes. It's not on top of my todo list to study that right now though and I
would not worry about it, but you asked how I noticed the array. :-)

[yurys, 2015-02-27 10:41:27]

Thanks for explaining! That was interesting. As for savings due to --fno-inline
I assume that it might be caused by extensive usage of template types defined in
InspectorTypeBuilder.h

[Daniel Bratell, 2015-02-27 12:54:53]

The CQ bit was checked by bratell@opera.com

[commit-bot: I haz the power, 2015-02-27 12:55:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/958893002/1

[commit-bot: I haz the power, 2015-02-27 14:33:22]

Committed patchset #1 (id:1) as
https://src.chromium.org/viewvc/blink?view=rev&revision=191000