Expanding Type Traits to make Vector use mem ops more.

Expanding Type Traits to make Vector use mem ops more.

Vector has several code paths depending on whether the encapsulated
object can be handled with memmove/memcpu/memset or not, and those
are used by many objects. Unfortunately that requires manual hinting
in each class because the type traits used are not strong enough.

By using type trait functions available in all modern compilers it's
possible to more intelligently select the most optimal code path.

Preferably the code would use the new type traits in C++ 11 but
unfortunately that requires a modern c++ library. Luckily, those
libraries are mostly just thin wrappers on top of de facto-standard
compiler extension functions anyway.

With clang this cuts away 105 KB of machine code in blink. Mostly by 
no longer needing copy constructor and assignment operators in many
classes so those can be stripped from the binary. 

With gcc the changes are differently. The binary is smaller but only 
by 5 KB. It's clear that many Vector methods have become more compact but
it seems gcc compensated by spending that space elsewhere (more inlining?).

I don't have as good measurement tools for Visual Studio but there was no
huge difference in footprint.

Performance, all this is from a noisy development computer with a 
non-stable cpu clock frequency (turbo ftl...):

In LayoutTests most changes are within noise levels. But it looks like 
large tables and flexboxes might be 1-5% faster. In ParserTests 
html5-full-render (macro-benchmark) became 2-3% faster.

clang footprint numbers:
Total change: -109940 bytes
===========================
  14 added, totalling +3397 bytes across 8 sources
  19 removed, totalling -13302 bytes across 6 sources
  8 grown, for a net change of +578 bytes (2268 bytes before, 2846 bytes after) across 6 sources
  230 shrunk, for a net change of -100613 bytes (190909 bytes before, 90296 bytes after) across 49 sources

Biggest changes:
 -84410 - Source: /home/bratell/src/chromium/src/third_party/WebKit/Source/wtf/Vector.h - (gained 784, lost 85194)
  -6934 - Source: /home/bratell/src/chromium/src/third_party/WebKit/Source/wtf/Deque.h - (gained 0, lost 6934)
  -2267 - Source: /home/bratell/src/chromium/src/third_party/WebKit/Source/core/animation/css/CSSAnimationData.cpp - (gained 904, lost 3171)
...
   +245 - Source: /home/bratell/src/chromium/src/third_party/WebKit/Source/core/svg/animation/SVGSMILElement.cpp - (gained 245, lost 0)

BUG=
R=jochen@chromium.org

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

[Daniel Bratell, 2014-09-18 14:33:17]

Patchset #5 (id:80001) has been deleted

[Daniel Bratell, 2014-09-18 21:45:26]

Patchset #7 (id:140001) has been deleted

[Daniel Bratell, 2014-09-18 21:45:46]

Patchset #5 (id:100001) has been deleted

[Daniel Bratell, 2014-09-18 21:46:18]

Patchset #2 (id:20001) has been deleted

[Daniel Bratell, 2014-09-18 21:48:44]

bratell@opera.com changed reviewers:
+ thakis@chomium.org

[Daniel Bratell, 2014-09-18 21:48:45]

thakis, this is the experimental change that caused me to ask about C++
libraries. It's possible you or someone else have done similar experiments in
the past but after bypassing the C++ library completely the results are fairly
good so I think it might be worth pursuing.

[Daniel Bratell, 2014-09-19 14:47:10]

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

[Daniel Bratell, 2014-09-19 14:47:10]

Now I've measured performance.

In LayoutTests most changes are within noise levels. Possibly significant
changes are that flexbox tests have become 4-5% faster, large-tables have become
2% faster, chapter-reflow 1% faster, and the micro test character_fallback 15%
slower. If it's reproducible it's much better than I had expected. Still, very
noisy to test on my computer.

In ParserTests html5-full-render (macro-benchmark) became 2-3% faster.
query-selector-all-attribute too. The micro benchmark simple-urls was 21%
slower.

Again, this is much better than I had expected. If it's true, and the code isn't
suddenly very broken (broken code can be faster than working code. :-) ).

[jochen (gone - plz use gerrit), 2014-09-22 09:43:30]

can you explain why the microbenchmarks become slower?

[Daniel Bratell, 2014-09-22 15:03:44]

On 2014/09/22 09:43:30, jochen (slow for reviews) wrote:
> can you explain why the microbenchmarks become slower?

One of them was probably no regression. Looking more careful at the results for
character_fallback, most runs (with or without the patch) is at the same speed.
One run without the patch was much faster (computer on turbo overdrive?) and
compared to that it looks like a regression but that is all.

The reproducible change is simple-urls which has dropped 20% but it is not easy
to say why. No Vector code that has changed is run in that code path (it tests
how fast it is to assign the href attribute), and looking at it with a
performance measurement tool (perf) there is no individual block that uses more
than 7-8% of the time. Nothing there seems related to a change to VectorTraits.

Also there is no change of machine code in core/dom or core/html that seems even
remotely relevant.

But the change in absolute numbers is small. Maybe small enough to just mean an
extra few cache misses. The time for one iteration in the test has gone from
~714 clock cycles to ~833 clock cycles (a loss of about 40 nanoseconds per
assignment on my computer).

I can keep digging but I don't think it will be meaningful except from a
curiosity point of view. I would be much more interested in knowing whether the
speedups on the bigger tests are real or just noise + wishful thinking.

[jochen (gone - plz use gerrit), 2014-09-22 15:05:41]

lgtm

[Daniel Bratell, 2014-09-22 15:23:12]

The CQ bit was checked by bratell@opera.com

[commit-bot: I haz the power, 2014-09-22 15:24:11]

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

[commit-bot: I haz the power, 2014-09-22 15:29:13]

Committed patchset #4 (id:120001) as 182427

[Nico, 2014-09-22 23:25:11]

thakis@chromium.org changed reviewers:
+ thakis@chromium.org

[Nico, 2014-09-22 23:25:11]

(you sent this to thakis@chomium.org (note missing 'r'), so i didn't see this
and didn't reply)

[Nico, 2014-09-23 01:26:32]

A revert of this CL (patchset #4 id:120001) has been created in
https://codereview.chromium.org/594763002/ by thakis@chromium.org.

The reason for reverting is: Broke developer builds on os x:
https://code.google.com/p/chromium/issues/detail?id=416715.