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/memcpy/memset or not. The fast path
with memops is used by many objects, but unfortunately that 
requires manual hinting in every 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. There were also
indications that some micro-benchmarks became 30% faster since reverting
an earlier version of this caused that size performance regressions.

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=183947

[Daniel Bratell, 2014-09-23 07:16:00]

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

[Daniel Bratell, 2014-09-23 07:19:36]

Patchset #1 is the same patch that was reviewed and landed in
https://codereview.chromium.org/581683002/ and that was then reverted because it
triggered a bug with precompiled headers in clang (mac only?).

Depending on how soon the fixed clang can become used, I will wait for that one
or try to figure out a workaround since I'm very curious to get a second,
official, opinion on the performance changes.

[Nico, 2014-09-23 18:12:12]

On 2014/09/23 07:19:36, Daniel Bratell wrote:
> Patchset #1 is the same patch that was reviewed and landed in
> https://codereview.chromium.org/581683002/ and that was then reverted because
it
> triggered a bug with precompiled headers in clang (mac only?).

It's a cross-platform bug, but it's only triggered when using PCHs. The blink
gyp files only use pch files on mac, for historical reasons.

> Depending on how soon the fixed clang can become used, I will wait for that
one
> or try to figure out a workaround since I'm very curious to get a second,
> official, opinion on the performance changes.

I'm in favor of waiting, but if we don't have the fix deployed within two weeks
I think this is harmless enough that I'm fine with you using some workaround
then.

[jochen (gone - plz use gerrit), 2014-09-26 18:46:38]

lgtm to commit once clang in chromium was updated to include the fix

[jochen (gone - plz use gerrit), 2014-10-07 11:24:10]

is this ready for landing?

[Daniel Bratell, 2014-10-07 12:41:54]

On 2014/10/07 11:24:10, jochen wrote:
> is this ready for landing?

Still waiting for an updated clang. I talked to hans@chromium.org yesterday
about it so now he knows that there are people waiting for one. He filed
https://code.google.com/p/chromium/issues/detail?id=420674 on himself, and said
that he just needed the google internal compiler people to declare some version
as "stable".

[Daniel Bratell, 2014-10-16 16:25:34]

On 2014/10/07 12:41:54, Daniel Bratell wrote:
> On 2014/10/07 11:24:10, jochen wrote:
> > is this ready for landing?
> 
> Still waiting for an updated clang. I talked to mailto:hans@chromium.org
yesterday
> about it so now he knows that there are people waiting for one. He filed
> https://code.google.com/p/chromium/issues/detail?id=420674 on himself, and
said
> that he just needed the google internal compiler people to declare some
version
> as "stable".

Since yesterday there is a new clang but hans asked us to not land anything that
depends on it for a few days so I probably land this during the weekend.

[Daniel Bratell, 2014-10-19 09:56:27]

The CQ bit was checked by bratell@opera.com

[commit-bot: I haz the power, 2014-10-19 09:57:28]

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

[commit-bot: I haz the power, 2014-10-19 11:05:52]

Committed patchset #1 (id:1) as 183947