REGRESSION(r183570): jslib-traverse-jquery is 22% slower
Created attachment 252100 [details] Patch
Comment on attachment 252100 [details] Patch Looks like I broke everything :(.
Created attachment 252112 [details] Patch
Comment on attachment 252112 [details] Patch r=me too.
Comment on attachment 252112 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=252112&action=review > Source/JavaScriptCore/ChangeLog:13 > + (b) the nodes are usually already sorted. I think they will always be sorted, originating from querySelector APIs which always return nodes in document order. :) > Source/JavaScriptCore/ChangeLog:22 > + 82% speedup on jslib-traverse-jquery, bringing us to 40% faster than > + the unregressed baseline. Kickass!
Comment on attachment 252112 [details] Patch Still broken :(. BTW, the nodes in the worst tests are never in order or reverse order. I don't know why yet.
Created attachment 252162 [details] Patch
Comment on attachment 252162 [details] Patch Attachment 252162 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/5776924949348352 New failing tests: fast/dom/navigator-detached-no-crash.html js/sort-large-array.html transitions/transition-end-event-multiple-03.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A2.1_T3.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A2.2_T1.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A2.2_T3.html fast/xmlhttprequest/xmlhttprequest-get.xhtml sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A2.1_T1.html http/tests/workers/worker-importScriptsOnError.html js/dom/regexp-caching.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A3_T2.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A3_T1.html js/reserved-words-strict.html fast/dom/plugin-attributes-enumeration.html js/dom/global-constructors-attributes-dedicated-worker.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A2.1_T2.html fast/dom/event-handler-attributes.html js/comparefn-sort-stability.html js/dom/global-constructors-attributes.html sputnik/Conformance/13_Function_Definition/13.2_Creating_Function_Objects/S13.2.1_A5_T1.html jquery/traversing.html js/Object-getOwnPropertyNames.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A2.2_T2.html
Created attachment 252165 [details] Archive of layout-test-results from ews104 for mac-mavericks-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews104 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Comment on attachment 252162 [details] Patch Attachment 252162 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/6060547409707008 New failing tests: fast/dom/navigator-detached-no-crash.html js/sort-large-array.html transitions/transition-end-event-multiple-03.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A2.1_T3.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A2.2_T1.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A2.2_T3.html fast/xmlhttprequest/xmlhttprequest-get.xhtml sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A2.1_T1.html http/tests/workers/worker-importScriptsOnError.html js/dom/regexp-caching.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A3_T2.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A3_T1.html js/reserved-words-strict.html fast/dom/plugin-attributes-enumeration.html js/dom/global-constructors-attributes-dedicated-worker.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A2.1_T2.html fast/dom/event-handler-attributes.html js/comparefn-sort-stability.html js/dom/global-constructors-attributes.html sputnik/Conformance/13_Function_Definition/13.2_Creating_Function_Objects/S13.2.1_A5_T1.html jquery/traversing.html js/Object-getOwnPropertyNames.html sputnik/Conformance/15_Native_Objects/15.4_Array/15.4.4/15.4.4.11_Array_prototype_sort/S15.4.4.11_A2.2_T2.html
Created attachment 252166 [details] Archive of layout-test-results from ews102 for mac-mavericks The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews102 Port: mac-mavericks Platform: Mac OS X 10.9.5
Created attachment 252195 [details] Patch
Created attachment 252250 [details] Patch
Comment on attachment 252250 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=252250&action=review > Source/JavaScriptCore/ChangeLog:29 > + The solution is simple enough: Call compareDocumentPosition(b, a) instead. Amazing. r=me too. > Source/JavaScriptCore/ChangeLog:48 > + Another option is for elements to keep a compareDocumentPosition cache, > + like a node list cache, which allows you to determine the absolute > + position of a node using a hash lookup. I will leave this as an exercise > + for kling. Or we can just wait for anttik to finish his legendary CoreNode refactoring where container nodes have arrays of children, and compareDocumentPosition can be implemented using simple pointer comparison for siblings. :]
Committed r183749: <http://trac.webkit.org/changeset/183749>
Comment on attachment 252250 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=252250&action=review > Source/JavaScriptCore/ChangeLog:40 > + A fully principled soultion to this problem would probably do something soultion