[Calendar] Fix minmax date#477
Closed
ArnaudD wants to merge 97 commits into
Closed
Conversation
…tate by reference, since the we already isolate it higher up in the API.
…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()
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)
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)
Conflicts: src/base/tests/benchmark/base-benchmark.html
Our benchmarks show which paths are the "hottest" in Attribute. This applies some micro optimizations to those functions.
… 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.
Member
|
FYI, this passes tests just looks like Travis is being a bit flaky.. |
…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 yui#453 (comment) 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)
Contributor
Author
|
I amended the last commit so your comments aren't visible anymore but the coding conventions ( |
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
a) Mainly to handle fact that private _subscribers/_afters are created lazily, so we use the public API where possible to assert. b) Also, to handle the fact that we removed default properties which shadowed default CE properties (bubbles, etc). That is a default override for ET was no longer required. c) Also to handle properties which are now lazily instantiated (targets) NOTE: All of this is private API. That is, we didn't have to changes any public API tests.
Made * support close to zero cost for folks who are not using it (80% case). We now set a flag, and don't bother looking for siblings, if no-one has subscribed using * (makes subscription a little heavier, but fire is the critical path). Also moved around some of the facade creation code and stack handling for no-event-lister impl (hasPotentialSubscribers). This still needs to be refined/validated for the stack use case. Testing ------- ✔ [Total]: Passed: 10726 Failed: 0 Total: 10811 (ignored 85) (8 minutes, 17 seconds) Numbers (Chrome 25) ------------------- This commit: new Base() x 19,495 Subscribe + Fire - 10 different events x 353 Fire - 10 different events, no listeners x 42,842 Publish - 10 different events x 146,300 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 21,896 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 56,486 EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 147,900 Fire With Payload - 10 listeners x 150,865 Fire - 10 listeners x 184,732 Fire With Payload - 2 listeners x 195,953 Fire - 2 listeners x 224,911 Publish x 1,848,491 Prior commit: new Base() x 18,956 Subscribe + Fire - 10 different events x 351 Fire - 10 different events, no listeners x 36,823 Publish - 10 different events x 148,715 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 23,381 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 55,777 EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 149,094 Fire With Payload - 10 listeners x 147,155 Fire - 10 listeners x 178,635 Fire With Payload - 2 listeners x 162,870 Fire - 2 listeners x 202,660 Publish x 1,701,478 3.8.1 new Base() x 14,689 Subscribe + Fire - 10 different events x 375 Fire - 10 different events, no listeners x 22,934 Publish - 10 different events x 123,922 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 20,431 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 46,436 EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 98,833 Fire With Payload - 10 listeners x 134,755 Fire - 10 listeners x 170,762 Fire With Payload - 2 listeners x 159,093 Fire - 2 listeners x 207,473 Publish x 1,567,016
a) queuable:false - this is the default value, no need to specify it. b) silent:true - this only impacts debug builds. This commit is based on the event-perf-nolisteners work. This just means there's less to iterate through when mixing configs. Not a massive/noticeable perf improvment, but cleans things up regardless. May help with older/slower browsers. Testing ------- All pass. [Total]: Passed: 10717 Failed: 0 Total: 10802 (ignored 85) (8 minutes, 18 seconds) Numbers (Chrome 25) ------------------ This Commit: Base x 15,821 ops/sec ±2.43% (87 runs sampled) MyBase x 15,401 ops/sec ±2.11% (93 runs sampled) MyBase with 10 simple value attributes x 10,244 ops/sec ±1.47% (91 runs sampled) MyBase with 20 varied attributes x 4,937 ops/sec ±2.79% (77 runs sampled) MyModel with 2 ad-hoc attrs x 13,827 ops/sec ±1.35% (94 runs sampled) Prior Commit: Base x 15,173 ops/sec ±2.47% (89 runs sampled) MyBase x 15,100 ops/sec ±2.74% (91 runs sampled) MyBase with 10 simple value attributes x 10,235 ops/sec ±2.11% (90 runs sampled) MyBase with 20 varied attributes x 4,936 ops/sec ±2.50% (81 runs sampled) MyModel with 2 ad-hoc attrs x 13,588 ops/sec ±2.06% (89 runs sampled)
arg manipulation. fireComplex() : Cache repeated . references, and created lesser used queues lazily (e.g. es.queue, es.afterQueue) NOTE: Contrary to the branch name, this is more focused at events with listeners, but it's here as a continuating of the no listener work since I'm deep into it. Testing ------- All pass. [Total]: Passed: 10726 Failed: 0 Total: 10811 (ignored 85) (8 minutes, 26 seconds) Numbers (Chrome 25) ------------------- This Commit: new BaseCore() x 59,674 new Base() x 17,680 Subscribe + Fire - 10 different events x 393 Fire - 10 different events, no listeners x 37,644 Publish - 10 different events x 133,419 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 21,427 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 55,955 EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 159,903 Fire With Payload - 10 listeners x 170,501 Fire - 10 listeners x 202,202 Fire With Payload - 2 listeners x 208,265 Fire - 2 listeners x 269,374 Publish x 1,858,518 Prior Commit: new BaseCore() x 57,335 new Base() x 16,856 Subscribe + Fire - 10 different events x 381 Fire - 10 different events, no listeners x 40,583 Publish - 10 different events x 132,423 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 20,590 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 53,017 EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 150,094 Fire With Payload - 10 listeners x 148,811 Fire - 10 listeners x 185,054 Fire With Payload - 2 listeners x 193,622 Fire - 2 listeners x 229,254 Publish x 1,707,517
1. Avoid slice/iteration for common signatures - fire("foo") and fire("foo", {})
2. Add private _fire(arr) to avoid reconverting arguments to array from et.fire() -> ce.fire()
3. Fixed one rare path, where we were passing the raw `arguments` to use by reference in
_monitor.
Big boost for Chrome, smaller boost for others, although still better than the original (see fire
related tests below).
NOTES:
a. The publish number variance is unrelated. Nothing in this code change touches publish
b. The benchmark tests have been changed as of this commit. I realized a couple of my
tests were using the same EventTarget for each iteration which was either bogging stuff done
(e.g. publishing a gazillion events), or resulting in less work than expected (e.g. publishing
and already published event instead of a fresh publish).
Testing
-------
All tests pass, except for known yogi test/io test failure (fails prior to this change also and in clean dev-3.x)
[Total]: Passed: 10725 Failed: 1 Total: 10811 (ignored 85) (8 minutes, 26 seconds)
[io-base Test Suite]: Passed: 39 Failed: 1 Total: 40 (ignored 0) (1.372 seconds)
testPOSTWithNoData
Values should be the same.
Expected: 200 (number)
Actual: 204 (number)
Numbers
-------
This commit:
Chrome 25
new BaseCore() x 58,060
new Base() x 24,375
Subscribe + Fire - 10 different events x 7,590
Fire - 10 different events, no listeners x 195,272
Publish - 10 different events x 45,946
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 22,581
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 63,541
EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 243,016
Fire With Payload - 10 listeners x 267,247
Fire - 10 listeners x 312,207
Fire With Payload - 2 listeners x 307,782
Fire - 2 listeners x 511,529
Publish x 416,336
FF 19
new BaseCore() x 23,653
new Base() x 10,278
Subscribe + Fire - 10 different events x 3,248
Fire - 10 different events, no listeners x 72,554
Publish - 10 different events x 20,867
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 11,214
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 26,821
EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 77,164
Fire With Payload - 10 listeners x 80,366
Fire - 10 listeners x 87,933
Fire With Payload - 2 listeners x 101,368
Fire - 2 listeners x 111,964
Publish x 180,157
Safari 6
new BaseCore() x 58,440
new Base() x 20,653
Subscribe + Fire - 10 different events x 5,137
Fire - 10 different events, no listeners x 144,626
Publish - 10 different events x 51,600
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 16,081
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 41,634
EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 151,295
Fire With Payload - 10 listeners x 84,037
Fire - 10 listeners x 82,022
Fire With Payload - 2 listeners x 153,113
Fire - 2 listeners x 154,749
Publish x 487,979
Prior commit:
Chrome 25
new BaseCore() x 58,222
new Base() x 20,923
Subscribe + Fire - 10 different events x 6,923
Fire - 10 different events, no listeners x 74,543
Publish - 10 different events x 46,005
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 22,479
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 58,373
EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 171,370
Fire With Payload - 10 listeners x 161,504
Fire - 10 listeners x 203,838
Fire With Payload - 2 listeners x 217,060
Fire - 2 listeners x 265,981
Publish x 394,612
FF 19
new BaseCore() x 23,768
new Base() x 9,561
Subscribe + Fire - 10 different events x 3,150
Fire - 10 different events, no listeners x 70,747
Publish - 10 different events x 21,088
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 10,909
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 26,416
EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 72,134
Fire With Payload - 10 listeners x 75,308
Fire - 10 listeners x 79,160
Fire With Payload - 2 listeners x 94,831
Fire - 2 listeners x 101,513
Publish x 180,391
Safari 6
new BaseCore() x 59,982
new Base() x 20,276
Subscribe + Fire - 10 different events x 4,813
Fire - 10 different events, no listeners x 102,961
Publish - 10 different events x 53,298
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 16,253
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 40,741
EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 133,001
Fire With Payload - 10 listeners x 83,356
Fire - 10 listeners x 81,567
Fire With Payload - 2 listeners x 129,808
Fire - 2 listeners x 136,671
Publish x 480,559
By checking `is monitored` criteria outside function.
May revisit to remove check inside _monitor later, bif we can do so for all _monitor
calls, but it's a fairly rare use case, so not that critical a path, so not worried about it
Testing
-------
All tests pass, except for known yogi test/io test failure (fails prior to this change also and in clean dev-3.x)
[Total]: Passed: 10725 Failed: 1 Total: 10811 (ignored 85) (8 minutes, 26 seconds)
[io-base Test Suite]: Passed: 39 Failed: 1 Total: 40 (ignored 0) (1.372 seconds)
testPOSTWithNoData
Numbers
-------
Chrome 25
This commit:
new BaseCore() x 58,892
new Base() x 24,668
Subscribe + Fire - 10 different events x 8,315
Fire - 10 different events, no listeners x 316,605
Publish - 10 different events x 44,614
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 24,552
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 67,265
EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 270,168
Fire With Payload - 10 listeners x 253,889
Fire - 10 listeners x 320,085
Fire With Payload - 2 listeners x 434,377
Fire - 2 listeners x 625,443
Publish x 470,998
Prior commit:
new BaseCore() x 55,420 ops/sec ±0.69% (92 runs sampled)
new Base() x 23,924 ops/sec ±1.53% (93 runs sampled)
Subscribe + Fire - 10 different events x 7,778 ops/sec ±1.71% (93 runs sampled)
Fire - 10 different events, no listeners x 199,091 ops/sec ±0.81% (90 runs sampled)
Publish - 10 different events x 45,317 ops/sec ±0.55% (95 runs sampled)
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 22,818 ops/sec ±1.55% (95 runs sampled)
EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 62,990 ops/sec ±1.49% (94 runs sampled)
EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 245,377 ops/sec ±2.05% (93 runs sampled)
Fire With Payload - 10 listeners x 234,145 ops/sec ±1.28% (89 runs sampled)
Fire - 10 listeners x 315,210 ops/sec ±0.58% (97 runs sampled)
Fire With Payload - 2 listeners x 320,415 ops/sec ±0.79% (96 runs sampled)
Fire - 2 listeners x 462,005 ops/sec ±0.38% (94 runs sampled)
Publish x 409,211 ops/sec ±0.37% (93 runs sampled)
Originally, the reliance on global ETs was making some tests useless. Without benchmark providing a trivial way to set up state for each "sample", this is as decent as we can get, without being too complicated (basing stuff on test.count). Reran some numbers across a few browsers, just to act as the baseline for tests going forward. ----- Chrome25 This Commit Publish x 222,381 new BaseCore() x 53,524 new Base() x 24,044 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 23,975 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 66,126 EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 284,488 Fire With Payload - 10 listeners x 293,837 Fire - 10 listeners x 450,277 Fire With Payload - 2 listeners x 372,498 Fire - 2 listeners x 605,252 Fire With Payload - 0 listeners x 4,698,338 Fire - 0 listeners x 5,243,252 Chrome25 3.8.1 Publish x 148,366 new BaseCore() x 54,417 new Base() x 15,960 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 22,248 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 49,948 EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 104,844 Fire With Payload - 10 listeners x 135,912 Fire - 10 listeners x 177,887 Fire With Payload - 2 listeners x 159,371 Fire - 2 listeners x 194,467 Fire With Payload - 0 listeners x 769,963 Fire - 0 listeners x 806,474 FF19 This Commit Publish x 174,510 new BaseCore() x 22,918 new Base() x 10,193 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 10,596 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 26,410 EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 78,645 Fire With Payload - 10 listeners x 77,227 Fire - 10 listeners x 87,631 Fire With Payload - 2 listeners x 100,945 Fire - 2 listeners x 110,833 Fire With Payload - 0 listeners x 1,627,725 Fire - 0 listeners x 2,149,124 FF19 3.8.1 Publish x 118,637 new BaseCore() x 23,548 new Base() x 8,311 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 10,535 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 23,139 EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 43,198 Fire With Payload - 10 listeners x 64,875 Fire - 10 listeners x 70,919 Fire With Payload - 2 listeners x 77,945 Fire - 2 listeners x 87,826 Fire With Payload - 0 listeners x 1,549,324 Fire - 0 listeners x 2,014,923 Safari6 This Commit Publish x 380,083 new BaseCore() x 61,902 new Base() x 21,892 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 16,449 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 43,362 EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 162,522 Fire With Payload - 10 listeners x 89,641 Fire - 10 listeners x 88,941 Fire With Payload - 2 listeners x 161,232 Fire - 2 listeners x 164,421 Fire With Payload - 0 listeners x 3,127,966 Fire - 0 listeners x 3,410,986 Safari6 3.8.1 Publish x 192,492 new BaseCore() x 58,579 new Base() x 15,095 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 10 listeners x 15,460 EventTarget Construction + Publish(foo) + Subscribe(foo) + Fire(foo) - 2 listeners x 37,705 EventTarget Construction + Publish(foo) + Fire(foo) - no listeners x 74,236 Fire With Payload - 10 listeners x 72,622 Fire - 10 listeners x 70,800 Fire With Payload - 2 listeners x 120,713 Fire - 2 listeners x 130,585 Fire With Payload - 0 listeners x 1,554,694 Fire - 0 listeners x 1,704,530
Conflicts: build/simpleyui/simpleyui-min.js
…event and simpleyui
There's an issue in 0.4.7 of this dependency, so backing down to the one before.
…2532185 Setting minimumDate or maximumDate now correctly disable nodes before or after theses dates.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Setting minimumDate or maximumDate now correctly disable nodes before or after theses dates.
This pull request fixes the following issues