Update Base's benchmark.js setup.
[WIP] Lower-level fix to improve new BaseCore() times. Store cfg in State by reference, since the we already isolate it higher up in the API.
[WIP] Initial drop for cached ATTRS aggregation across instances, to speed up construction for > 1 instance use case.

* attribute, attribute-core, base, base-core unit tests all pass.
* app, widget, widget-parent/child, dd tests all pass.

Benchmark sample, on Chrome 23

3.8.0

MyBaseCore with 20 varied attributes (using perf. best practices) x 11,805 ops/sec ±1.89% (89 runs sampled)
MyBaseCore with 20 varied attributes x 7,039 ops/sec ±3.74% (73 runs sampled)
MyBaseCore with 10 simple value attributes x 21,069 ops/sec ±1.66% (93 runs sampled)
MyBaseCore x 60,417 ops/sec ±2.23% (90 runs sampled)
BaseCore x 61,683 ops/sec ±0.92% (86 runs sampled)

This commit

MyBaseCore with 20 varied attributes (using perf. best practices) x 20,857 ops/sec ±1.94% (94 runs sampled)
MyBaseCore with 20 varied attributes x 9,384 ops/sec ±4.12% (71 runs sampled)
MyBaseCore with 10 simple value attributes x 36,140 ops/sec ±2.03% (92 runs sampled)
MyBaseCore x 78,936 ops/sec ±3.45% (89 runs sampled)
BaseCore x 81,023 ops/sec ±2.64% (90 runs sampled)

This is an initial baseline pass to validate:

1) The potential benefits of the approach.
2) The feasibility of the approach - by fully passing unit test suites.

The focus was on making sure we have passing feature tests, there by establishing
the minimal performance savings available, without compromising stability.

That is, we should be able to get *at least* this much savings, but likely more,
since we may be over-isolating some of the configs/default values, based on the focus
to have passing tests.

Next Steps For BaseCore:

a) Look into isolation code paths, to make sure we're optimially isolating cfgs and default values, and
   not iterating more than we need to.

b) Look at some lower-level, potentially micro optimizations to speed up the Attribute->State interface,
   maybe leveraging ES5 where available.

Next Steps for Base:

a) Optimize Event firing/publishing for the "No Listeners" path, so new Base() approaches new BaseCore()
Micro Optimizations, plus cleaning up ATTRS cache a little.

Key wins seem to be:

a) Avoiding the delete operator, and just set to undefined/false
b) Using cfg by reference where possible (as opposed to getting/setting in state again)

As a result of a) had to update an attribute test for the _getAttrCfg protected method, since
we leave more internal meta-properties in the attr config hash (instanced of deleting them).

attribute, base, widget, dd and app tests all pass.

NOTE: We can get a bit more of a performance boost, once we clean up app's id handling to avoid
the addAttr overide (we need to update one of of state's internal meta-properties [lazy],
for that, which we could avoid). Without this, there was a failing model-rest-sync test
(discussed with Eric).

This commit (Chrome 23):

MyBaseCore with 20 varied attributes (using perf. best practices) x 24,336 ops/sec ±1.70% (93 runs sampled)
MyBaseCore with 20 varied attributes x 9,748 ops/sec ±5.56% (64 runs sampled)
MyBaseCore with 10 simple value attributes x 51,166 ops/sec ±1.91% (93 runs sampled)
MyBaseCore x 159,111 ops/sec ±1.58% (94 runs sampled)
BaseCore x 164,114 ops/sec ±1.69% (94 runs sampled)

Last commit (ATTRS cache):

MyBaseCore with 20 varied attributes (using perf. best practices) x 20,857 ops/sec ±1.94% (94 runs sampled)
MyBaseCore with 20 varied attributes x 9,384 ops/sec ±4.12% (71 runs sampled)
MyBaseCore with 10 simple value attributes x 36,140 ops/sec ±2.03% (92 runs sampled)
MyBaseCore x 78,936 ops/sec ±3.45% (89 runs sampled)
BaseCore x 81,023 ops/sec ±2.64% (90 runs sampled)

3.8.0:

MyBaseCore with 20 varied attributes (using perf. best practices) x 11,805 ops/sec ±1.89% (89 runs sampled)
MyBaseCore with 20 varied attributes x 7,039 ops/sec ±3.74% (73 runs sampled)
MyBaseCore with 10 simple value attributes x 21,069 ops/sec ±1.66% (93 runs sampled)
MyBaseCore x 60,417 ops/sec ±2.23% (90 runs sampled)
BaseCore x 61,683 ops/sec ±0.92% (86 runs sampled)
[WIP] More sharing attribute config by reference optimizations

Centered around avoiding repeated calls to State.get, across method
boundaries, by passing an already retrieved attribute cfg across
private method calls.

Mainly targets get()/set() operations.

attribute, base, dd, widget, app tests all pass

This commit (Chrome 24):

MyBaseCore with 10 simple value attributes - get x 7,769,862 ops/sec ±1.37% (91 runs sampled)
MyBaseCore with 10 simple value attributes - set x 2,027,186 ops/sec ±2.37% (86 runs sampled)

MyBaseCore with 20 varied attributes (using perf. best practices) x 25,421 ops/sec ±1.33% (94 runs sampled)
MyBaseCore with 20 varied attributes x 9,060 ops/sec ±6.35% (59 runs sampled)
MyBaseCore with 10 simple value attributes x 54,249 ops/sec ±1.23% (94 runs sampled)
MyBaseCore x 163,314 ops/sec ±1.49% (91 runs sampled)
BaseCore x 174,555 ops/sec ±1.08% (94 runs sampled)

Prior commit (Chrome 24):

MyBaseCore with 10 simple value attributes - get x 2,475,836 ops/sec ±0.31% (96 runs sampled)
MyBaseCore with 10 simple value attributes - set x 1,077,515 ops/sec ±0.24% (96 runs sampled)

MyBaseCore with 20 varied attributes (using perf. best practices) x 25,250 ops/sec ±1.24% (95 runs sampled)
MyBaseCore with 20 varied attributes x 9,442 ops/sec ±6.42% (62 runs sampled)
MyBaseCore with 10 simple value attributes x 54,512 ops/sec ±0.43% (93 runs sampled)
MyBaseCore x 149,460 ops/sec ±0.83% (92 runs sampled)
BaseCore x 158,574 ops/sec ±0.93% (93 runs sampled)

3.8.0 (Chrome 24):

MyBaseCore with 10 simple value attributes - get x 2,436,501 ops/sec ±1.34% (87 runs sampled)
MyBaseCore with 10 simple value attributes - set x 589,829 ops/sec ±1.01% (94 runs sampled)

MyBaseCore with 20 varied attributes (using perf. best practices) x 12,753 ops/sec ±1.37% (92 runs sampled)
MyBaseCore with 20 varied attributes x 6,644 ops/sec ±4.20% (70 runs sampled)
MyBaseCore with 10 simple value attributes x 22,942 ops/sec ±0.44% (92 runs sampled)
MyBaseCore x 57,039 ops/sec ±1.37% (91 runs sampled)
BaseCore x 61,830 ops/sec ±1.21% (91 runs sampled)
Merge branch 'attrs-perf' of git://github.com/sdesai/yui3 into sdesai-attrs-perf
Merge branch 'attr-base-perf-bench' into attr-base-perf
Merge branch 'sdesai-attrs-perf' into attr-base-perf

Conflicts:
	src/base/tests/benchmark/base-benchmark.html
Add micro optimizations to Attribute's "hot" path.

Our benchmarks show which paths are the "hottest" in Attribute. This
applies some micro optimizations to those functions.
Update Base's benchmarks to include 3.8.1 seed (commented out).
Merge branch 'dev-3.x' into attrs-perf
Pulling in the last good commit from ericf/attr-base-perf
[WIP] Removed double clone when aggregating static subattrs (rare use case).

app, attribute, base, calendar, charts, dd, widget, widget-parent/child all pass
through yogi test (phantomjs).

I wouldn't expect it to hurt or help performance noticeably. Only impact for the
common use case should be an additional `if` check during _filterAttrCfgs. The
benchmark numbers seem to show that.

This commit (Chrome 24):

BaseCore x 174,910 ops/sec ±1.09% (94 runs sampled)
MyBaseCore x 167,695 ops/sec ±1.21% (92 runs sampled)
MyBaseCore with 10 simple value attributes x 58,359 ops/sec ±0.46% (96 runs sampled)
MyBaseCore with 20 varied attributes x 9,496 ops/sec ±5.50% (64 runs sampled)
MyBaseCore with 20 varied attributes (using perf. best practices) x 23,907 ops/sec ±1.38% (93 runs sampled)
MyBaseCore with 10 simple value attributes - set x 2,509,904 ops/sec ±0.26% (94 runs sampled)
MyBaseCore with 10 simple value attributes - get x 10,574,867 ops/sec ±0.39% (93 runs sampled)

Prior commit (Chrome 24):

BaseCore x 173,127 ops/sec ±0.78% (93 runs sampled)
MyBaseCore x 161,185 ops/sec ±1.00% (94 runs sampled)
MyBaseCore with 10 simple value attributes x 54,756 ops/sec ±1.20% (92 runs sampled)
MyBaseCore with 20 varied attributes x 9,718 ops/sec ±7.04% (56 runs sampled)
MyBaseCore with 20 varied attributes (using perf. best practices) x 25,758 ops/sec ±1.60% (92 runs sampled)
MyBaseCore with 10 simple value attributes - set x 2,512,378 ops/sec ±0.26% (95 runs sampled)
MyBaseCore with 10 simple value attributes - get x 10,510,340 ops/sec ±0.49% (95 runs sampled)

NOTE: The benchmark showed enough fluctuation/variance across runs for the prior commit to
occasionally win out on some tests. But they stayed within the ballpark/variance
range.

Wanted to get this in as a WIP commit, since it seems to be logically correct (tests pass). Want
to take a second pass to optimize the rare use case, where we have statically defined subattrs. Try
switching from split() to substring() maybe in _aggregateAttrs - although with the caching, it's not
that critical.
Added jshint:maxlen overrides for log lines
Avoid repeated jshint:maxlen, by moving to module scope
Identify B2G/FFOS as mobile in Y.UA
Fixed issue where we were trying to re-add attributes, already added by a subclass.

This ate into our gains a little bit (compared to prior attrs-perf commits), but still
substantially better than 3.8.1. Numbers below.

Also validated that the issues highlighted by Tripps charts test case are
accounted for. See https://github.com/yui/yui3/pull/453#issuecomment-14310679

All tests pass:

attrs-perf/src $ yogi test
[Total]: Passed: 10717 Failed: 0 Total: 10802 (ignored 85) (8 minutes, 19 seconds)

NOTE: Had to make a low-level perf optization call based on FF being an major
outlier in the following test: http://jsperf.com/in-vs-hasownproperty/6. Hence
included FF numbers below also. We can revisit if required - flip-flopped between
the 2 many times, and chose hop, because it saved some of the gains we lost for
the major chunk (webkit) of target browsers. Worth pinging FF about?

Chrome 25:

This Commit

BaseCore x 160,543 ops/sec ±0.68% (94 runs sampled)
MyBaseCore x 149,699 ops/sec ±1.15% (91 runs sampled)
MyBaseCore with 10 simple value attributes x 45,741 ops/sec ±1.43% (93 runs sampled)
MyBaseCore with 20 varied attributes x 7,791 ops/sec ±5.81% (61 runs sampled)
MyBaseCore with 20 varied attributes (using perf. best practices) x 18,961 ops/sec ±1.17% (90 runs sampled)
MyBaseCore with 10 simple value attributes - set x 2,439,898 ops/sec ±0.35% (94 runs sampled)
MyBaseCore with 10 simple value attributes - get x 10,296,544 ops/sec ±0.61% (92 runs sampled)

Prior Commit

BaseCore x 167,934 ops/sec ±1.17% (95 runs sampled)
MyBaseCore x 164,318 ops/sec ±1.40% (93 runs sampled)
MyBaseCore with 10 simple value attributes x 52,033 ops/sec ±1.19% (95 runs sampled)
MyBaseCore with 20 varied attributes x 8,312 ops/sec ±6.99% (55 runs sampled)
MyBaseCore with 20 varied attributes (using perf. best practices) x 23,259 ops/sec ±1.35% (92 runs sampled)
MyBaseCore with 10 simple value attributes - set x 2,780,588 ops/sec ±3.29% (91 runs sampled)
MyBaseCore with 10 simple value attributes - get x 10,517,876 ops/sec ±0.40% (92 runs sampled)

3.8.1

BaseCore x 59,459 ops/sec ±1.42% (94 runs sampled)
MyBaseCore x 54,524 ops/sec ±1.70% (93 runs sampled)
MyBaseCore with 10 simple value attributes x 21,651 ops/sec ±1.22% (91 runs sampled)
MyBaseCore with 20 varied attributes x 6,255 ops/sec ±5.47% (62 runs sampled)
MyBaseCore with 20 varied attributes (using perf. best practices) x 12,244 ops/sec ±1.45% (92 runs sampled)
MyBaseCore with 10 simple value attributes - set x 533,183 ops/sec ±0.51% (95 runs sampled)
MyBaseCore with 10 simple value attributes - get x 2,373,572 ops/sec ±0.38% (88 runs sampled)

Firefox 19:

This Commit

BaseCore x 59,213 ops/sec ±0.95% (86 runs sampled)
MyBaseCore x 54,453 ops/sec ±0.86% (87 runs sampled)
MyBaseCore with 10 simple value attributes x 29,714 ops/sec ±2.64% (89 runs sampled)
MyBaseCore with 20 varied attributes x 11,533 ops/sec ±0.93% (89 runs sampled)
MyBaseCore with 20 varied attributes (using perf. best practices) x 16,562 ops/sec ±0.93% (88 runs sampled)
MyBaseCore with 10 simple value attributes - set x 923,897 ops/sec ±0.75% (96 runs sampled)
MyBaseCore with 10 simple value attributes - get x 5,773,198 ops/sec ±0.92% (92 runs sampled)

3.8.1

BaseCore x 24,210 ops/sec ±1.79% (79 runs sampled)
MyBaseCore x 24,322 ops/sec ±2.74% (79 runs sampled)
MyBaseCore with 10 simple value attributes x 14,059 ops/sec ±1.49% (92 runs sampled)
MyBaseCore with 20 varied attributes x 6,645 ops/sec ±0.92% (90 runs sampled)
MyBaseCore with 20 varied attributes (using perf. best practices) x 8,001 ops/sec ±0.57% (91 runs sampled)
MyBaseCore with 10 simple value attributes - set x 334,317 ops/sec ±5.55% (93 runs sampled)
MyBaseCore with 10 simple value attributes - get x 2,045,595 ops/sec ±0.79% (95 runs sampled)
Changing the mobile flag to ffos to show it is a FFOS device
Merge branch 'dev-3.x' into b2g
[WIP] First pass at no-listener optimizations

1) Reduce publish cost, by having more stuff on CE proto.

2) Reduce publish cost, by having _subscribers/_afters arrays be lazy.

3) Reduce new ET cost/new CE cost by mimimizing props to iterate through
   (avoid "undefined" props, masking falsey default values).

4) Reduce new ET cost, by having targets map be lazy.

5) Reduce new ET cost by avoiding stamp() on _yuievt. Didn't seem like id was
   being used.

6) Provide fast track for fires with no potential subscribers, but
   with a defaultFn (needs testing)

All library tests run through `yogi test` pass.

[Total]: Passed: 10726 Failed: 0 Total: 10811 (ignored 85) (8 minutes, 24 seconds)

NOTE: Will check in updated tests, due to removed/modified internal properties and
lazy _subscribers/_afters arrays, in separate commit.

Next up for evaluation
----------------------

A) See if we can have defaults in ET, be inherited (flip Y.CE.prototype if you will),
   instead of mixed in. Tests show that new Y.CE is better than Object.get(), which
   was considered. So staying with FnConstructors for now. http://jsperf.com/create-new

B) The type/Y.cached handling is worth optimizing, as mentioned before, by passing
   through the calculated type.

C) See if we can have a private getSubs(), hasSubs() which can return faster, and avoid
   creating arrays, unless there are subscribers. The above 2 methods are public, so
   can't mess with those.

D) See if we can get by with holding onto the opts for publish, without creating a new
   Y.CustomEvent, on publish (maybe optionally, based on lazyPublish config?).

Numbers
-------

This commit (ops/sec):

new Base() x 18,894
Publish x 1,714,575
Publish - 10 different events x 152,180
Fire - 10 different events, no listeners x 36,957
EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 158,325
Subscribe + Fire - 10 different events x 381
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 23,252
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 58,334
Fire With Payload - 10 listeners x 130,708
Fire - 10 listeners x 163,150
Fire With Payload - 2 listeners x 181,028
Fire - 2 listeners x 195,069

3.8.1 (ops/sec):

new Base() x 15,606
Publish x 1,662,980
Publish - 10 different events x 124,112
Fire - 10 different events, no listeners x 20,458
EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 97,666
Subscribe + Fire - 10 different events x 365
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 22,867
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 51,528
Fire With Payload - 10 listeners x 135,688
Fire - 10 listeners x 167,362
Fire With Payload - 2 listeners x 151,447
Fire - 2 listeners x 206,144