Better storage of HTML entities.

The entity table contained pointers which both makes it big and prevents
it from being reused as-is from the binary. This changes it to make
the storage more compact by replacing pointers with offsets into a
shared string. Also switching to more compact data types.

The new database will look like:

static const LChar staticEntityStringStorage[] = {
'A', 'E', 'l', 'i', 'g',
';',
'A', 'M', 'P',
';',
'A', 'a', 'c', 'u', 't', 'e',
';',
...

static const HTMLEntityTableEntry staticEntityTable[2231] = {
    { 0x000C6, 0, 0, 5 }, // &AElig
    { 0x000C6, 0, 0, 6 }, // Æ
    { 0x00026, 0, 6, 3 }, // &AMP
    { 0x00026, 0, 6, 4 }, // &
    { 0x000C1, 0, 10, 6 }, // &Aacute
...

The binary will shrink by about 20-35 KB (depending on architecture),
the memory usage should shrink by similar numbers for every
renderer (since the memory now can be shared between renderers) and
there will be a tiny startup time improvement due to
fewer relocation blocks and less to read from disk.

It accomplishes the savings by avoiding pointers in the data (resolving pointers
during startup is expensive), using one string instead of 2000+, not storing the
trailing NUL byte, ordering the members for minimum padding, using minimal size
data types and reusing the same string space for things like "amp;" and "amp".

BUG=352141
R=

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

[Daniel Bratell, 2014-03-13 14:20:34]

abarth, could you please look at this size/memory/startup time optimization?
(Asking you since you reviewed the last patch here but let me know if someone
else would be more suitable).

[abarth-chromium, 2014-03-17 17:37:27]

Neat!  LGTM

One question about the build-time cost of this search below.

https://codereview.chromium.org/199103002/diff/1/Source/core/html/parser/crea...
File Source/core/html/parser/create-html-entity-table (right):

https://codereview.chromium.org/199103002/diff/1/Source/core/html/parser/crea...
Source/core/html/parser/create-html-entity-table:127: # and that is NP-Complete
or worse.
I bet most of the hits are just stripping the trailing ;

Maybe it's not worth trying to find the other substrings?  I guess this runs at
build time...  How long does the script take with and without this search?

[eseidel, 2014-03-17 17:42:34]

Very cool.  I suspect we have many other instances of static data which we're
needlessly storing on the heap.

[Daniel Bratell, 2014-03-17 19:55:21]

On a computer that is slower than most the script running time has gone from 30
ms to 60 ms.

It is O(n^2) but it just scans a few MB of memory in total which computers are
fast at. If someone adds, say, 10000 more entities, then we need to rethink
this, but I believe the current set of entities has been rather static for a
while?

As for saving space by reusing substrings, yes, I think that is only (or almost
only) semi-colon and not semi-colon strings, but it was an obvious thing to do.
I think the total save was a few KB at most so it's possible to sacrifice if
needed.

[abarth-chromium, 2014-03-17 20:11:52]

60ms is fine :)

[Daniel Bratell, 2014-03-18 08:09:15]

The CQ bit was checked by bratell@opera.com

[commit-bot: I haz the power, 2014-03-18 08:09:17]

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

[commit-bot: I haz the power, 2014-03-18 08:12:17]

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

[commit-bot: I haz the power, 2014-03-18 08:12:17]

Try jobs failed on following builders:
  tryserver.blink on win_blink_rel

[Daniel Bratell, 2014-03-18 09:25:40]

The CQ bit was checked by bratell@opera.com

[commit-bot: I haz the power, 2014-03-18 09:25:45]

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

[commit-bot: I haz the power, 2014-03-18 10:05:35]

Change committed as 169438