97270 2012-09-20 16:09:28 -0700 DOM-in-JavaScript performance experiments 2017-07-18 08:30:03 -0700 1 1 1 Unclassified WebKit WebCore JavaScript 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 1 abarth abarth alex ap arv barraclough dmikurube dominicc eric ggaren haraken mjs sam oldest_to_newest 724951 0 abarth 2012-09-20 16:09:28 -0700 This bug is just a holder for DOM-in-JavaScript performance experiment patches. If you don't care about DOM-in-JavaScript performance, you can safely ignore it. 724953 1 165006 abarth 2012-09-20 16:10:49 -0700 Created attachment 165006 Patch to measure the cost of pimpl for Node (-3% on Dromaeo/dom-traverse; -5% on Dromaeo/dom-modify) 724963 2 165007 abarth 2012-09-20 16:27:34 -0700 Created attachment 165007 Patch to Dromaeo/dom-traverse to compare CPP DOM and JS DOM (29.32% better with JS DOM) 724965 3 haraken 2012-09-20 16:30:18 -0700 ccing arv@, who has been also prototyping DOM-in-JavaScript. 724990 4 abarth 2012-09-20 17:04:03 -0700 Looks like arv has been running some experiments too: https://github.com/arv/JS-DOM-Test 725490 5 arv 2012-09-21 06:52:53 -0700 Let me see if I understand this correctly. The pure cpp impact is -5% but we get almost 30% faster from JS? 725530 6 abarth 2012-09-21 08:28:22 -0700 We don't have enough data to draw those conclusions, but so far that's about the scale of the performance changes. These patches are just rough approximations. Haraken has also suggested some more experiments, which I'd like to run. 726236 7 sam 2012-09-22 23:49:59 -0700 Can you explain a bit more about what this experiment is looking at? 726283 8 abarth 2012-09-23 12:10:05 -0700 > Can you explain a bit more about what this experiment is looking at? Currently all of the DOM structure is stored outside the JavaScript VM. We're experimenting with the idea of uploading some amount of this state into the JavaScript VM. At least from these simple experiments, there does appear to a significant amount of performance on the table. I certainly don't have a complete design in mind. At the moment, I'm leaning towards some sort of state representation that can be shared by the JavaScript VM and the CPP implementation. In particular, to get the full advantage of the JavaScript VM's memory management, we'd likely want this state to be understandable (and compactable) by the garbage collector. We're just exploring the design space. The performance characteristics of JavaScript VMs have changed radically since the design of the current bindings. It seems likely that there are different performance considerations now. If you're interested in this topic, I'm happy to involve you in more of the discussions. 726311 9 sam 2012-09-23 16:14:10 -0700 (In reply to comment #8) > > Can you explain a bit more about what this experiment is looking at? > > Currently all of the DOM structure is stored outside the JavaScript VM. We're experimenting with the idea of uploading some amount of this state into the JavaScript VM. At least from these simple experiments, there does appear to a significant amount of performance on the table. > > I certainly don't have a complete design in mind. At the moment, I'm leaning towards some sort of state representation that can be shared by the JavaScript VM and the CPP implementation. In particular, to get the full advantage of the JavaScript VM's memory management, we'd likely want this state to be understandable (and compactable) by the garbage collector. > > We're just exploring the design space. The performance characteristics of JavaScript VMs have changed radically since the design of the current bindings. It seems likely that there are different performance considerations now. If you're interested in this topic, I'm happy to involve you in more of the discussions. Please do. And also please involve the folks working on JavaScriptCore. 726337 10 abarth 2012-09-23 19:19:24 -0700 Anyone in particular? 726348 11 sam 2012-09-23 20:06:04 -0700 (In reply to comment #10) > Anyone in particular? At the very least Geoff Garen. 728966 12 mjs 2012-09-26 14:13:16 -0700 Adam, I am intrigued by the possibility of 30% speedups. How do I interpret the results of the patched Dromaeo/dom-traverse? I get output like this, how do I interpret it? Which are the C++ DOM numbers and which are the JS DOM numbers? -------- 233.2742048370791 228.85231409663135 1419 1451.8 250.69890229530947 Time: avg 3583.6254212290196 runs/s median 0 runs/s stdev 106.78560737165455 runs/s min 3374.3917685085466 runs/s max 3653.791186857055 runs/s 728974 13 abarth 2012-09-26 14:21:37 -0700 > Adam, I am intrigued by the possibility of 30% speedups. Me too! I should warn you that these are just experiments. There isn't a real design here. Just some evidence that we might want to look into moving move of the DOM into JavaScript. > How do I interpret the results of the patched Dromaeo/dom-traverse? I get output like this, how do I interpret it? Which are the C++ DOM numbers and which are the JS DOM numbers? If you look in the dom-traverse patch, you'll see the following two lines: + document.body.cppFirstChild = document.body.firstChild; + document.body.jsFirstChild = mirror(document.body.firstChild); What this means is that document.body.cppFirstChild points to the normal implementation of the DOM: namely backed by CPP code in WebCore. On the other hand, document.body.jsFirstChild is a JavaScript-only mirror of the DOM structure, created just by wiring up firstChild/lastChild/nextSibling/previousSibling properties up on empty JavaScript objects. (I haven't tested the mirror function, so it might have bugs.) If you look in the nextSibling test, you'll see the following line of code: + var cur = document.body.jsFirstChild; // Change to document.body.cppFirstChild That means the test is running with the JavaScript version of the DOM tree. If you change jsFirstChild to cppFirstChild, you'll be running with the CPP version of the DOM tree. You can run test once with jsFirstChild and once with cppFirstChild to compare the performance differences between the two implementations of the tree. The way I've been doing that with with the run-perf-tests script, which creates nice graphs for comparing the output: $ ./Tools/Scripts/run-perf-tests PerformanceTests/Dromaeo/dom-traverse.html You can also just compare the avg runs/s numerically. 728975 14 abarth 2012-09-26 14:23:10 -0700 (I should note that I changed both the nextSibling and the previousSibling tests at the same time. You can also delete one or the other since they're very similar tests.) 728989 15 mjs 2012-09-26 14:38:26 -0700 Thanks for the tips! Here are some results I got: JS - Safari TOT avg 253710.8 runs/s CPP - Safari TOT avg 499435.80000000005 runs/s That looks like the JS-based version is about 50% slower, not 30% faster. Am I misunderstanding the test or what the claim was? I wanted to try the test in Chrome Canary but it doesn't seem to run there. 729009 16 abarth 2012-09-26 15:03:19 -0700 > Here are some results I got: Fascinating. > That looks like the JS-based version is about 50% slower, not 30% faster. Am I misunderstanding the test or what the claim was? Here are the numbers I got (five minutes ago) with DumpRenderTree in the chromium port: $ ./out/Release/DumpRenderTree file:///src/abarth-webkit/PerformanceTests/Dromaeo/dom-traverse.html == js == avg 326188 runs/s median 0 runs/s stdev 1218.1536848854498 runs/s min 325071 runs/s max 328243 runs/s == cpp == avg 266485.3966033966 runs/s median 0 runs/s stdev 671.5778183390692 runs/s min 265506 runs/s max 267288.48851148854 runs/s That shows the JS implementation running faster than the CPP implementation. I need re-run these tests on a Mac to compare the absolute numbers between JSC and V8. We might be getting different outcomes here because there are two moving pieces: 1) The performance of the JSC and the V8 bindings code. 2) The performance of the underlying JavaScript engine. 729039 17 mjs 2012-09-26 16:02:26 -0700 (In reply to comment #16) > > Here are some results I got: > > Fascinating. > > > That looks like the JS-based version is about 50% slower, not 30% faster. Am I misunderstanding the test or what the claim was? > > Here are the numbers I got (five minutes ago) with DumpRenderTree in the chromium port: > > $ ./out/Release/DumpRenderTree file:///src/abarth-webkit/PerformanceTests/Dromaeo/dom-traverse.html > > == js == > > avg 326188 runs/s > median 0 runs/s > stdev 1218.1536848854498 runs/s > min 325071 runs/s > max 328243 runs/s > > == cpp == > > avg 266485.3966033966 runs/s > median 0 runs/s > stdev 671.5778183390692 runs/s > min 265506 runs/s > max 267288.48851148854 runs/s > > That shows the JS implementation running faster than the CPP implementation. I need re-run these tests on a Mac to compare the absolute numbers between JSC and V8. > > We might be getting different outcomes here because there are two moving pieces: > > 1) The performance of the JSC and the V8 bindings code. > 2) The performance of the underlying JavaScript engine. I will try to rearrange the test to be a single file and print both results, so it can easily be loaded in different browsers. Because I'm also curious what the results are in different versions. And that is probably easier for me than building chromium webkit. 729047 18 abarth 2012-09-26 16:12:15 -0700 Ok, I just ran WebKit@129710 in a Mac Pro in both chromium-mac and apple-mac: == js == chromium-mac: avg 190979.59999999998 runs/s apple-mac: avg 178240.40000000002 runs/s == cpp == chromium-mac: avg 148605.44592533214 runs/s apple-mac: avg 388969 runs/s The performance ordering appears to be: apple-mac-cpp > chromium-mac-js > apple-mac-js > chromium-mac-cpp 729051 19 abarth 2012-09-26 16:18:53 -0700 With a small tweak to how we build the JS objets, I can make the JS version outperform the CPP version in JSC as well: chromium-mac-js2: 191981.8 runs/s apple-mac-js2: 472447.4 runs/s The difference is that js2 uses createMirrorDOMNode() to add the properties in the same order for every JavaScript "DOM node." (Attaching updated perf test shortly.) 729057 20 165894 abarth 2012-09-26 16:22:18 -0700 Created attachment 165894 Version in which JS outperforms CPP in JavaScriptCore as well 729061 21 abarth 2012-09-26 16:31:53 -0700 Recoding my command lines for copy-pasta later: $ DYLD_FRAMEWORK_PATH=/Users/abarth/svn/webkit/WebKitBuild/Release ./WebKitBuild/Release/DumpRenderTree file:///Users/abarth/svn/webkit/PerformanceTests/Dromaeo/dom-traverse.html $ ./out/Release/DumpRenderTree.app/Contents/MacOS/DumpRenderTree file:///Users/abarth/svn/webkit/PerformanceTests/Dromaeo/dom-traverse.html 729114 22 mjs 2012-09-26 18:14:59 -0700 (In reply to comment #18) > Ok, I just ran WebKit@129710 in a Mac Pro in both chromium-mac and apple-mac: > > == js == > chromium-mac: avg 190979.59999999998 runs/s > apple-mac: avg 178240.40000000002 runs/s > > == cpp == > chromium-mac: avg 148605.44592533214 runs/s > apple-mac: avg 388969 runs/s > > The performance ordering appears to be: > > apple-mac-cpp > chromium-mac-js > apple-mac-js > chromium-mac-cpp Seems the main issue identified here is that V8 DOM bindings are very slow compared to JSC DOM bindings. (I will look into the version that seems to show a benefit in JSC as well.) 729119 23 haraken 2012-09-26 18:24:35 -0700 > > apple-mac-cpp > chromium-mac-js > apple-mac-js > chromium-mac-cpp > > Seems the main issue identified here is that V8 DOM bindings are very slow compared to JSC DOM bindings. V8 DOM bindings are still very slower than JSC DOM bindings, that's true to some extent. (I've been optimizing the performance for months.) That being said, conceptually, I think that apple-mac-js should be faster than apple-mac-cpp. In apple-mac-cpp, .nextSibling needs to call back JSC binding, do some value conversion from JS to C++, do something in WebCore, do some value conversion from C++ to JS, and return back to JSC. On the other hand, in apple-mac-js, .nextSibling doesn't need to call back JSC binding. Everything completes without leaving the JIT code. In that sense, in the world where we optimize things appropriately, apple-mac-js will become faster than apple-mac-cpp. 729156 24 abarth 2012-09-26 19:49:35 -0700 > Seems the main issue identified here is that V8 DOM bindings are very slow compared to JSC DOM bindings. That may well be true (and is something we can work on in another bug), but Comment #19 seems to indiciate that the first JS implementation was not being fully optimized by JSC. In the second JS implementation, the JS version appears to be significantly faster than the CPP version, even in JSC. 729170 25 mjs 2012-09-26 20:26:52 -0700 (In reply to comment #24) > > Seems the main issue identified here is that V8 DOM bindings are very slow compared to JSC DOM bindings. > > That may well be true (and is something we can work on in another bug), but Comment #19 seems to indiciate that the first JS implementation was not being fully optimized by JSC. In the second JS implementation, the JS version appears to be significantly faster than the CPP version, even in JSC. As mentioned, I'm definitely interested in that and will look into it. 729243 26 ggaren 2012-09-26 23:38:20 -0700 From <http://trac.webkit.org/wiki/DOMInJavaScript?version=3>, and the dom-traverse test case, it looks like the main goal here is to optimize DOM traversal. Are there other goals? 729255 27 haraken 2012-09-26 23:50:57 -0700 (In reply to comment #26) > From <http://trac.webkit.org/wiki/DOMInJavaScript?version=3>, and the dom-traverse test case, it looks like the main goal here is to optimize DOM traversal. Are there other goals? FYI, this slide explains other motivations: https://docs.google.com/a/chromium.org/presentation/d/1X3hExrBtjXIUVqmDArAdEh9JYQudhCPvgSguilK54iE/edit?pli=1#slide=id.p 729258 28 abarth 2012-09-26 23:57:35 -0700 Thanks for noticing the wiki page I'm writing up. I think I've got it into a more sane shape now. Here's a strawman design for we might actually be able to realize these speedups: https://trac.webkit.org/wiki/DOMInJavaScript > it looks like the main goal here is to optimize DOM traversal. Are there other goals? Speeding up DOM traversal is certainly near the top of my list because it's so widely used. If we do a good job with DOM traversal, we might be able to re-use the mechanism in other places where it shows a speedup. For example, haraken has some data showing that nodeType and className are the hotest DOM properties. There might also be opportunities for optimizing these properties by uploading them into the JavaScript engine. Another benefit of this approach is that it somewhat simplifies garbage collection (e.g., it might help fix Bug 88834). The idea here is that by uploading the DOM tree into the JavaScript engine, the JavaScript engine's garbage collector has a better understanding of which objects are keeping which other objects alive. The usefulness of this information depends on how the garbage collector works. For example, a generational garbage collector might need only examine DOM edges in the new space rather than needing to crawl the entire DOM tree (i.e., the portion in the old space). 729264 29 abarth 2012-09-27 00:01:22 -0700 > FYI, this slide explains other motivations: https://docs.google.com/a/chromium.org/presentation/d/1X3hExrBtjXIUVqmDArAdEh9JYQudhCPvgSguilK54iE/edit?pli=1#slide=id.p I don't agree with some of the conclusions in this slide deck. In particular, I'm hopeful that DOM-in-JavaScript will actually be faster, especially for JS-heavy workloads. That's why I created this bug initially: to experiment with performance. 729516 30 haraken 2012-09-27 07:41:25 -0700 > https://trac.webkit.org/wiki/DOMInJavaScript Thank you very much for the write up! The approach looks good. One question: Are you intending to create wrapper objects for all DOM nodes? Or are you intending to create wrapper objects only for DOM nodes that are touched by JavaScript (as is done in the current JSC/V8+WebKit)? The latter idea would be feasible in a following way (and might be better/worse in terms of performance). As a fast path, in a case where a wrapper object exists, .nextSibling is realized by normal JavaScript property access. As a slow path, in a case where a wrapper object does not exist, .nextSibling is realized by Node::nextSibling() as is done in the current WebKit. 729522 31 abarth 2012-09-27 07:51:17 -0700 > One question: Are you intending to create wrapper objects for all DOM nodes? Or are you intending to create wrapper objects only for DOM nodes that are touched by JavaScript (as is done in the current JSC/V8+WebKit)? The proposal in the wiki page is to create wrappers for all DOM nodes. Before doing that, of course, we'll need to look at the impact on memory and performance. > The latter idea would be feasible in a following way (and might be better/worse in terms of performance). As a fast path, in a case where a wrapper object exists, .nextSibling is realized by normal JavaScript property access. As a slow path, in a case where a wrapper object does not exist, .nextSibling is realized by Node::nextSibling() as is done in the current WebKit. The trade-off is in that approach need to reserve space both in Node and in its wrapper for nextSibling. Depending on the wrapper rate, this can either be a win or a loss. We'll probably need to try a few designs before we find the best one. Would you mind adding a section comparing the optional-wrapper and mandatory-wrapper approaches to the wiki page? 729526 32 abarth 2012-09-27 07:55:37 -0700 I should also say that if you have storage for nextSibling in Node, another approach is to keep both copies up to date. In that case, JS would read the data from the JS object and CPP would read the data from the CPP object. The write operation (e.g., setNextSibling) would write to both locations. For purposes of discussion, we might want to call this the "write through" approach (and we should probably add it to the wiki as well). 729528 33 haraken 2012-09-27 07:57:45 -0700 (In reply to comment #31) > We'll probably need to try a few designs before we find the best one. Would you mind adding a section comparing the optional-wrapper and mandatory-wrapper approaches to the wiki page? Sure! Another disadvantage of the optional-wrapper approach is that it won't contribute to simplifying the GC. Either way I'll write them up tomorrow. 729989 34 mjs 2012-09-27 16:35:51 -0700 Adding Gavin Barraclough to Cc, I had a good conversation with him recently about plans to speed up DOM property access for JavaScriptCore. He said that JSC folks have discussed letting the JIT have sufficient understanding of some DOM accessors to make them efficient without having to modify the layout of DOM nodes or implement anything in JS. From what I can gather of the approach outlined in this bug, it seems that it would likely have a memory cost, and a speed cost for DOM traversal and mutation from C++. I am concerned about these potential costs, because it seems they would affect speed of core operations like HTML parsing and style resolution. Since JSC+WebKit, as far as I know, already has the fastest DOM traversal of any browser engine even with no changes, it would be a tough call whether a further ~1.2x speedup to DOM traversal would outweigh such costs. Maybe there is a plan to mitigate these downsides. If so, I am interested in learning more about that. Anyway - though the approach Gavin described to me sounds like it may more technically challenging (you'd have to understand and modify JIT code), it seems much less likely to hurt memory use or access speed from C++ code. So I found it to be a very intriguing idea. Since the JavaScriptCore team has a track record of success in making really wicked fast DOM bindings, I think it is worth considering their input in this area. It might also be useful to have some conversations about this by email or in person, and not just in bug comments. 729997 35 mjs 2012-09-27 16:39:10 -0700 (In reply to comment #29) > > FYI, this slide explains other motivations: https://docs.google.com/a/chromium.org/presentation/d/1X3hExrBtjXIUVqmDArAdEh9JYQudhCPvgSguilK54iE/edit?pli=1#slide=id.p > > I don't agree with some of the conclusions in this slide deck. In particular, I'm hopeful that DOM-in-JavaScript will actually be faster, especially for JS-heavy workloads. That's why I created this bug initially: to experiment with performance. One experiment that would help us learn about likely perf characteristics of a DOM implemented completely in JavaScript would be to try reimplementing some more complex DOM methods in JS. Seems like a trivial accessor like firstChild is the best possible case. 730035 36 abarth 2012-09-27 17:09:06 -0700 Interesting. I hadn't considered the approach of teaching the JIT more about the structure of DOM objects. As haraken writes in Comment #23, you're still going to run up against the limitation of needing to follow a pointer from the JSObject to the Node and then back to the other JSObject. As long as there are two objects and only one representation of the tree, one of the two kinds of objects is going to need to transit the graph by way of the other. I guess the logical conclusion of that thought process is that we should try to merge the wrapper object and the wrapped object so that neither needs to consult the other in order to transit the graph. > One experiment that would help us learn about likely perf characteristics of a DOM implemented completely in JavaScript would be to try reimplementing some more complex DOM methods in JS. Seems like a trivial accessor like firstChild is the best possible case. I wasn't suggesting implementing the entire DOM in JavaScript. The proposal in <http://trac.webkit.org/wiki/DOMInJavaScript> just suggests moving the tree representation. In any case, all of this is very much open for discussion and I welcome everyone's input, especially JSC hackers. :) 730634 37 haraken 2012-09-28 07:18:57 -0700 (In reply to comment #31) > We'll probably need to try a few designs before we find the best one. Would you mind adding a section comparing the optional-wrapper and mandatory-wrapper approaches to the wiki page? Done. Please edit it freely. 730873 38 sam 2012-09-28 12:15:48 -0700 Can you state the goal of these experiments? What benchmarks/scenarios are you trying to improve on? It seems a bit odd to me to start with a solution. 730901 39 abarth 2012-09-28 12:41:05 -0700 > Can you state the goal of these experiments? What benchmarks/scenarios are you trying to improve on? See Comment #28. > It seems a bit odd to me to start with a solution. This bug is about experimenting with an alternative approach for implement some DOM bindings. The goal is to learn about the performance characteristics of the approach by comparing its scores on various benchmarks. The approach might turn out to be a better or worse performance trade-off than the current approach. That's what I'm hoping to learn from these experiments. I could have chosen to perform these experiments in a secret branch of WebKit, but I decided to perform them here on this bug so that other folks in the community can participate in the discussion if they so choose. As I wrote in Comment #0, if you're not interested in the performance characteristics of this approach, you can safely ignore this bug thread. 165006 2012-09-20 16:10:49 -0700 2012-09-20 16:10:49 -0700 Patch to measure the cost of pimpl for Node (-3% on Dromaeo/dom-traverse; -5% on Dromaeo/dom-modify) pimpl.patch text/plain 3225 abarth ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL2RvbS9Eb2N1bWVudC5oIGIvU291cmNlL1dlYkNv cmUvZG9tL0RvY3VtZW50LmgKaW5kZXggZDgxMTljMy4uNDNmMjYzMCAxMDA2NDQKLS0tIGEvU291 cmNlL1dlYkNvcmUvZG9tL0RvY3VtZW50LmgKKysrIGIvU291cmNlL1dlYkNvcmUvZG9tL0RvY3Vt ZW50LmgKQEAgLTE2MDcsMTAgKzE2MDcsMTIgQEAgaW5saW5lIGJvb2wgTm9kZTo6aXNEb2N1bWVu dE5vZGUoKSBjb25zdAogaW5saW5lIE5vZGU6Ok5vZGUoRG9jdW1lbnQqIGRvY3VtZW50LCBDb25z dHJ1Y3Rpb25UeXBlIHR5cGUpCiAgICAgOiBtX25vZGVGbGFncyh0eXBlKQogICAgICwgbV9kb2N1 bWVudChkb2N1bWVudCkKLSAgICAsIG1fcHJldmlvdXMoMCkKLSAgICAsIG1fbmV4dCgwKQorICAg ICwgbV9pbXBsKGFkb3B0UHRyKG5ldyBOb2RlSW1wbCkpCiAgICAgLCBtX3JlbmRlcmVyKDApCiB7 CisgICAgbV9pbXBsLT5tX3ByZXZpb3VzID0gMDsKKyAgICBtX2ltcGwtPm1fbmV4dCA9IDA7CisK ICAgICBpZiAoZG9jdW1lbnQpCiAgICAgICAgIGRvY3VtZW50LT5ndWFyZFJlZigpOwogI2lmICFk ZWZpbmVkKE5ERUJVRykgfHwgKGRlZmluZWQoRFVNUF9OT0RFX1NUQVRJU1RJQ1MpICYmIERVTVBf Tk9ERV9TVEFUSVNUSUNTKQpkaWZmIC0tZ2l0IGEvU291cmNlL1dlYkNvcmUvZG9tL05vZGUuY3Bw IGIvU291cmNlL1dlYkNvcmUvZG9tL05vZGUuY3BwCmluZGV4IGFlZjY2OWMuLjEzMzgwMDcgMTAw NjQ0Ci0tLSBhL1NvdXJjZS9XZWJDb3JlL2RvbS9Ob2RlLmNwcAorKysgYi9Tb3VyY2UvV2ViQ29y ZS9kb20vTm9kZS5jcHAKQEAgLTQxNywxMCArNDE3LDEwIEBAIE5vZGU6On5Ob2RlKCkKICAgICBp ZiAoQVhPYmplY3RDYWNoZTo6YWNjZXNzaWJpbGl0eUVuYWJsZWQoKSAmJiBkb2MgJiYgZG9jLT5h eE9iamVjdENhY2hlRXhpc3RzKCkpCiAgICAgICAgIGRvYy0+YXhPYmplY3RDYWNoZSgpLT5yZW1v dmUodGhpcyk7CiAgICAgCi0gICAgaWYgKG1fcHJldmlvdXMpCi0gICAgICAgIG1fcHJldmlvdXMt PnNldE5leHRTaWJsaW5nKDApOwotICAgIGlmIChtX25leHQpCi0gICAgICAgIG1fbmV4dC0+c2V0 UHJldmlvdXNTaWJsaW5nKDApOworICAgIGlmIChtX2ltcGwtPm1fcHJldmlvdXMpCisgICAgICAg IG1faW1wbC0+bV9wcmV2aW91cy0+c2V0TmV4dFNpYmxpbmcoMCk7CisgICAgaWYgKG1faW1wbC0+ bV9uZXh0KQorICAgICAgICBtX2ltcGwtPm1fbmV4dC0+c2V0UHJldmlvdXNTaWJsaW5nKDApOwog CiAgICAgaWYgKGRvYykKICAgICAgICAgZG9jLT5ndWFyZERlcmVmKCk7CkBAIC0yODEyLDggKzI4 MTIsOCBAQCB2b2lkIE5vZGU6OnJlcG9ydE1lbW9yeVVzYWdlKE1lbW9yeU9iamVjdEluZm8qIG1l bW9yeU9iamVjdEluZm8pIGNvbnN0CiAgICAgVHJlZVNoYXJlZDxOb2RlLCBDb250YWluZXJOb2Rl Pjo6cmVwb3J0TWVtb3J5VXNhZ2UobWVtb3J5T2JqZWN0SW5mbyk7CiAgICAgU2NyaXB0V3JhcHBh YmxlOjpyZXBvcnRNZW1vcnlVc2FnZShtZW1vcnlPYmplY3RJbmZvKTsKICAgICBpbmZvLmFkZE1l bWJlcihtX2RvY3VtZW50KTsKLSAgICBpbmZvLmFkZE1lbWJlcihtX25leHQpOwotICAgIGluZm8u YWRkTWVtYmVyKG1fcHJldmlvdXMpOworICAgIGluZm8uYWRkTWVtYmVyKG1faW1wbC0+bV9uZXh0 KTsKKyAgICBpbmZvLmFkZE1lbWJlcihtX2ltcGwtPm1fcHJldmlvdXMpOwogICAgIGlmIChtX3Jl bmRlcmVyKQogICAgICAgICBpbmZvLmFkZE1lbWJlcihtX3JlbmRlcmVyLT5zdHlsZSgpKTsKIH0K ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJDb3JlL2RvbS9Ob2RlLmggYi9Tb3VyY2UvV2ViQ29yZS9k b20vTm9kZS5oCmluZGV4IDgyMTRkOTguLmRmZWY4YTMxIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2Vi Q29yZS9kb20vTm9kZS5oCisrKyBiL1NvdXJjZS9XZWJDb3JlL2RvbS9Ob2RlLmgKQEAgLTE2NCw4 ICsxNjQsOCBAQCBwdWJsaWM6CiAgICAgdmlydHVhbCBOb2RlVHlwZSBub2RlVHlwZSgpIGNvbnN0 ID0gMDsKICAgICBDb250YWluZXJOb2RlKiBwYXJlbnROb2RlKCkgY29uc3Q7CiAgICAgRWxlbWVu dCogcGFyZW50RWxlbWVudCgpIGNvbnN0OwotICAgIE5vZGUqIHByZXZpb3VzU2libGluZygpIGNv bnN0IHsgcmV0dXJuIG1fcHJldmlvdXM7IH0KLSAgICBOb2RlKiBuZXh0U2libGluZygpIGNvbnN0 IHsgcmV0dXJuIG1fbmV4dDsgfQorICAgIE5vZGUqIHByZXZpb3VzU2libGluZygpIGNvbnN0IHsg cmV0dXJuIG1faW1wbC0+bV9wcmV2aW91czsgfQorICAgIE5vZGUqIG5leHRTaWJsaW5nKCkgY29u c3QgeyByZXR1cm4gbV9pbXBsLT5tX25leHQ7IH0KICAgICBQYXNzUmVmUHRyPE5vZGVMaXN0PiBj aGlsZE5vZGVzKCk7CiAgICAgTm9kZSogZmlyc3RDaGlsZCgpIGNvbnN0OwogICAgIE5vZGUqIGxh c3RDaGlsZCgpIGNvbnN0OwpAQCAtMjYxLDggKzI2MSw4IEBAIHB1YmxpYzoKICAgICBib29sIGlz QmxvY2tGbG93T3JCbG9ja1RhYmxlKCkgY29uc3Q7CiAgICAgCiAgICAgLy8gVGhlc2UgbG93LWxl dmVsIGNhbGxzIGdpdmUgdGhlIGNhbGxlciByZXNwb25zaWJpbGl0eSBmb3IgbWFpbnRhaW5pbmcg dGhlIGludGVncml0eSBvZiB0aGUgdHJlZS4KLSAgICB2b2lkIHNldFByZXZpb3VzU2libGluZyhO b2RlKiBwcmV2aW91cykgeyBtX3ByZXZpb3VzID0gcHJldmlvdXM7IH0KLSAgICB2b2lkIHNldE5l eHRTaWJsaW5nKE5vZGUqIG5leHQpIHsgbV9uZXh0ID0gbmV4dDsgfQorICAgIHZvaWQgc2V0UHJl dmlvdXNTaWJsaW5nKE5vZGUqIHByZXZpb3VzKSB7IG1faW1wbC0+bV9wcmV2aW91cyA9IHByZXZp b3VzOyB9CisgICAgdm9pZCBzZXROZXh0U2libGluZyhOb2RlKiBuZXh0KSB7IG1faW1wbC0+bV9u ZXh0ID0gbmV4dDsgfQogCiAgICAgdmlydHVhbCBib29sIGNhbkNvbnRhaW5SYW5nZUVuZFBvaW50 KCkgY29uc3QgeyByZXR1cm4gZmFsc2U7IH0KIApAQCAtODAyLDggKzgwMiwxMSBAQCBwcml2YXRl OgogCiAgICAgbXV0YWJsZSB1aW50MzJfdCBtX25vZGVGbGFnczsKICAgICBEb2N1bWVudCogbV9k b2N1bWVudDsKLSAgICBOb2RlKiBtX3ByZXZpb3VzOwotICAgIE5vZGUqIG1fbmV4dDsKKyAgICBz dHJ1Y3QgTm9kZUltcGwgeworICAgICAgICBOb2RlKiBtX3ByZXZpb3VzOworICAgICAgICBOb2Rl KiBtX25leHQ7CisgICAgfTsKKyAgICBPd25QdHI8Tm9kZUltcGw+IG1faW1wbDsKICAgICBSZW5k ZXJPYmplY3QqIG1fcmVuZGVyZXI7CiAKIHB1YmxpYzoK 165007 2012-09-20 16:27:34 -0700 2012-09-20 16:27:34 -0700 Patch to Dromaeo/dom-traverse to compare CPP DOM and JS DOM (29.32% better with JS DOM) dom-traverse.patch text/plain 2881 abarth ZGlmZiAtLWdpdCBhL1BlcmZvcm1hbmNlVGVzdHMvRHJvbWFlby9yZXNvdXJjZXMvZHJvbWFlby93 ZWIvdGVzdHMvZG9tLXRyYXZlcnNlLmh0bWwgYi9QZXJmb3JtYW5jZVRlc3RzL0Ryb21hZW8vcmVz b3VyY2VzL2Ryb21hZW8vd2ViL3Rlc3RzL2RvbS10cmF2ZXJzZS5odG1sCmluZGV4IDk5ZmE4ZDgu LmZkYzkzZGQgMTAwNjQ0Ci0tLSBhL1BlcmZvcm1hbmNlVGVzdHMvRHJvbWFlby9yZXNvdXJjZXMv ZHJvbWFlby93ZWIvdGVzdHMvZG9tLXRyYXZlcnNlLmh0bWwKKysrIGIvUGVyZm9ybWFuY2VUZXN0 cy9Ecm9tYWVvL3Jlc291cmNlcy9kcm9tYWVvL3dlYi90ZXN0cy9kb20tdHJhdmVyc2UuaHRtbApA QCAtMiw2ICsyLDM3IEBACiA8aGVhZD4KIDxzY3JpcHQgc3JjPSIuLi9odG1scnVubmVyLmpzIj48 L3NjcmlwdD4KIDxzY3JpcHQ+CitmdW5jdGlvbiBmaW5kTGFzdFNpYmxpbmcobm9kZSkgeworICB3 aGlsZShub2RlLm5leHRTaWJsaW5nKQorICAgIG5vZGUgPSBub2RlLm5leHRTaWJsaW5nOworICBy ZXR1cm4gbm9kZTsKK30KKworZnVuY3Rpb24gbWlycm9yKHJlYWxSb290KSB7CisgIHZhciBtaXJy b3JSb290ID0ge307CisKKyAgdmFyIHJlYWxDdXJyZW50ID0gcmVhbFJvb3Q7CisgIHZhciBtaXJy b3JDdXJyZW50ID0gbWlycm9yUm9vdDsKKworICB3aGlsZSAocmVhbEN1cnJlbnQpIHsKKworICAg IGlmIChyZWFsQ3VycmVudC5maXJzdENoaWxkKSB7CisgICAgICBtaXJyb3JDdXJyZW50LmZpcnN0 Q2hpbGQgPSBtaXJyb3IocmVhbEN1cnJlbnQuZmlyc3RDaGlsZCk7CisgICAgICBtaXJyb3JDdXJy ZW50Lmxhc3RDaGlsZCA9IGZpbmRMYXN0U2libGluZyhtaXJyb3JDdXJyZW50LmZpcnN0Q2hpbGQp OworICAgIH0KKworICAgIGlmIChyZWFsQ3VycmVudC5uZXh0U2libGluZykgeworICAgICAgbWly cm9yQ3VycmVudC5uZXh0U2libGluZyA9IHt9OworICAgICAgbWlycm9yQ3VycmVudC5uZXh0U2li bGluZy5wcmV2aW91c1NpYmxpbmcgPSBtaXJyb3JDdXJyZW50OworICAgIH0KKworICAgIHJlYWxD dXJyZW50ID0gcmVhbEN1cnJlbnQubmV4dFNpYmxpbmc7CisgICAgbWlycm9yQ3VycmVudCA9IG1p cnJvckN1cnJlbnQubmV4dFNpYmxpbmc7CisgIH0KKworICByZXR1cm4gbWlycm9yUm9vdDsKK30K Kwogd2luZG93Lm9ubG9hZCA9IGZ1bmN0aW9uKCl7CiBzdGFydFRlc3QoImRvbS10cmF2ZXJzZSIs ICdjNmMzYTkwNScpOwogCkBAIC0xNywzNyArNDgsMTMgQEAgdmFyIGh0bWwgPSBkb2N1bWVudC5i b2R5LmlubmVySFRNTDsKIAkJdmFyIGRpdiA9IGRvY3VtZW50LmNyZWF0ZUVsZW1lbnQoImRpdiIp OwogCQlkaXYuaW5uZXJIVE1MID0gaHRtbDsKIAkJZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZCgg ZGl2ICk7Ci0JfSk7Ci0KLQl0ZXN0KCAiZmlyc3RDaGlsZCIsIGZ1bmN0aW9uKCl7Ci0JCXZhciBu b2RlcyA9IGRvY3VtZW50LmJvZHkuY2hpbGROb2RlcywgbmwgPSBub2Rlcy5sZW5ndGg7Ci0KLQkJ Zm9yICggdmFyIGkgPSAwOyBpIDwgbnVtOyBpKysgKSB7Ci0JCQlmb3IgKCB2YXIgaiA9IDA7IGog PCBubDsgaisrICkgewotCQkJCXZhciBjdXIgPSBub2Rlc1tqXTsKLQkJCQl3aGlsZSAoIGN1ciAp Ci0JCQkJCWN1ciA9IGN1ci5maXJzdENoaWxkOwotCQkJCXJldCA9IGN1cjsKLQkJCX0KLQkJfQot CX0pOwotCi0JdGVzdCggImxhc3RDaGlsZCIsIGZ1bmN0aW9uKCl7Ci0JCXZhciBub2RlcyA9IGRv Y3VtZW50LmJvZHkuY2hpbGROb2RlcywgbmwgPSBub2Rlcy5sZW5ndGg7Ci0KLQkJZm9yICggdmFy IGkgPSAwOyBpIDwgbnVtOyBpKysgKSB7Ci0JCQlmb3IgKCB2YXIgaiA9IDA7IGogPCBubDsgaisr ICkgewotCQkJCXZhciBjdXIgPSBub2Rlc1tqXTsKLQkJCQl3aGlsZSAoIGN1ciApCi0JCQkJCWN1 ciA9IGN1ci5sYXN0Q2hpbGQ7Ci0JCQkJcmV0ID0gY3VyOwotCQkJfQotCQl9CisgICAgZG9jdW1l bnQuYm9keS5jcHBGaXJzdENoaWxkID0gZG9jdW1lbnQuYm9keS5maXJzdENoaWxkOworICAgIGRv Y3VtZW50LmJvZHkuanNGaXJzdENoaWxkID0gbWlycm9yKGRvY3VtZW50LmJvZHkuZmlyc3RDaGls ZCk7CiAJfSk7CiAKIAl0ZXN0KCAibmV4dFNpYmxpbmciLCBmdW5jdGlvbigpewogCQlmb3IgKCB2 YXIgaSA9IDA7IGkgPCBudW0gKiAyOyBpKysgKSB7Ci0JCQl2YXIgY3VyID0gZG9jdW1lbnQuYm9k eS5maXJzdENoaWxkOworCQkJdmFyIGN1ciA9IGRvY3VtZW50LmJvZHkuanNGaXJzdENoaWxkOyAv LyBDaGFuZ2UgdG8gZG9jdW1lbnQuYm9keS5jcHBGaXJzdENoaWxkCiAJCQl3aGlsZSAoIGN1ciAp CiAJCQkJY3VyID0gY3VyLm5leHRTaWJsaW5nOwogCQkJcmV0ID0gY3VyOwpAQCAtNTYsMjEgKzYz LDEzIEBAIHZhciBodG1sID0gZG9jdW1lbnQuYm9keS5pbm5lckhUTUw7CiAKIAl0ZXN0KCAicHJl dmlvdXNTaWJsaW5nIiwgZnVuY3Rpb24oKXsKIAkJZm9yICggdmFyIGkgPSAwOyBpIDwgbnVtICog MjsgaSsrICkgewotCQkJdmFyIGN1ciA9IGRvY3VtZW50LmJvZHkubGFzdENoaWxkOworCQkJdmFy IGN1ciA9IGRvY3VtZW50LmJvZHkuanNGaXJzdENoaWxkOyAvLyBDaGFuZ2UgdG8gZG9jdW1lbnQu Ym9keS5jcHBGaXJzdENoaWxkCiAJCQl3aGlsZSAoIGN1ciApCiAJCQkJY3VyID0gY3VyLnByZXZp b3VzU2libGluZzsKIAkJCXJldCA9IGN1cjsKIAkJfQogCX0pOwogCi0JdGVzdCggImNoaWxkTm9k ZXMiLCBmdW5jdGlvbigpewotCQlmb3IgKCB2YXIgaSA9IDA7IGkgPCBudW07IGkrKyApIHsKLQkJ CXZhciBub2RlcyA9IGRvY3VtZW50LmJvZHkuY2hpbGROb2RlczsKLQkJCWZvciAoIHZhciBqID0g MDsgaiA8IG5vZGVzLmxlbmd0aDsgaisrICkKLQkJCQlyZXQgPSBub2Rlc1tqXTsKLQkJfQotCX0p OwotCiBlbmRUZXN0KCk7CiB9OwogPC9zY3JpcHQ+Cg== 165894 2012-09-26 16:22:18 -0700 2012-09-26 16:22:18 -0700 Version in which JS outperforms CPP in JavaScriptCore as well bug-97270-20120926162137.patch text/plain 3129 abarth SW5kZXg6IFBlcmZvcm1hbmNlVGVzdHMvRHJvbWFlby9yZXNvdXJjZXMvZHJvbWFlby93ZWIvdGVz dHMvZG9tLXRyYXZlcnNlLmh0bWwKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gUGVyZm9ybWFuY2VUZXN0cy9Ecm9t YWVvL3Jlc291cmNlcy9kcm9tYWVvL3dlYi90ZXN0cy9kb20tdHJhdmVyc2UuaHRtbAkocmV2aXNp b24gMTI5NzEwKQorKysgUGVyZm9ybWFuY2VUZXN0cy9Ecm9tYWVvL3Jlc291cmNlcy9kcm9tYWVv L3dlYi90ZXN0cy9kb20tdHJhdmVyc2UuaHRtbAkod29ya2luZyBjb3B5KQpAQCAtMiw2ICsyLDQ2 IEBACiA8aGVhZD4KIDxzY3JpcHQgc3JjPSIuLi9odG1scnVubmVyLmpzIj48L3NjcmlwdD4KIDxz Y3JpcHQ+CitmdW5jdGlvbiBmaW5kTGFzdFNpYmxpbmcobm9kZSkgeworICB3aGlsZShub2RlLm5l eHRTaWJsaW5nKQorICAgIG5vZGUgPSBub2RlLm5leHRTaWJsaW5nOworICByZXR1cm4gbm9kZTsK K30KKworZnVuY3Rpb24gY3JlYXRlTWlycm9yRE9NTm9kZSgpIHsKKyAgdmFyIG1pcnJvck5vZGUg PSB7fTsKKyAgbWlycm9yTm9kZS5maXJzdENoaWxkID0gbnVsbDsKKyAgbWlycm9yTm9kZS5sYXN0 Q2hpbGQgPSBudWxsOworICBtaXJyb3JOb2RlLm5leHRTaWJsaW5nID0gbnVsbDsKKyAgbWlycm9y Tm9kZS5wcmV2aW91c1NpYmxpbmcgPSBudWxsOworICByZXR1cm4gbWlycm9yTm9kZTsKK30KKwor ZnVuY3Rpb24gbWlycm9yKHJlYWxSb290KSB7CisgIHZhciBtaXJyb3JSb290ID0gY3JlYXRlTWly cm9yRE9NTm9kZSgpOworCisgIHZhciByZWFsQ3VycmVudCA9IHJlYWxSb290OworICB2YXIgbWly cm9yQ3VycmVudCA9IG1pcnJvclJvb3Q7CisKKyAgd2hpbGUgKHJlYWxDdXJyZW50KSB7CisKKyAg ICBpZiAocmVhbEN1cnJlbnQuZmlyc3RDaGlsZCkgeworICAgICAgbWlycm9yQ3VycmVudC5maXJz dENoaWxkID0gbWlycm9yKHJlYWxDdXJyZW50LmZpcnN0Q2hpbGQpOworICAgICAgbWlycm9yQ3Vy cmVudC5sYXN0Q2hpbGQgPSBmaW5kTGFzdFNpYmxpbmcobWlycm9yQ3VycmVudC5maXJzdENoaWxk KTsKKyAgICB9CisKKyAgICBpZiAocmVhbEN1cnJlbnQubmV4dFNpYmxpbmcpIHsKKyAgICAgIG1p cnJvckN1cnJlbnQubmV4dFNpYmxpbmcgPSBjcmVhdGVNaXJyb3JET01Ob2RlKCk7CisgICAgICBt aXJyb3JDdXJyZW50Lm5leHRTaWJsaW5nLnByZXZpb3VzU2libGluZyA9IG1pcnJvckN1cnJlbnQ7 CisgICAgfQorCisgICAgcmVhbEN1cnJlbnQgPSByZWFsQ3VycmVudC5uZXh0U2libGluZzsKKyAg ICBtaXJyb3JDdXJyZW50ID0gbWlycm9yQ3VycmVudC5uZXh0U2libGluZzsKKyAgfQorCisgIHJl dHVybiBtaXJyb3JSb290OworfQorCiB3aW5kb3cub25sb2FkID0gZnVuY3Rpb24oKXsKIHN0YXJ0 VGVzdCgiZG9tLXRyYXZlcnNlIiwgJ2M2YzNhOTA1Jyk7CiAKQEAgLTE3LDM3ICs1NywxMyBAQCB2 YXIgaHRtbCA9IGRvY3VtZW50LmJvZHkuaW5uZXJIVE1MOwogCQl2YXIgZGl2ID0gZG9jdW1lbnQu Y3JlYXRlRWxlbWVudCgiZGl2Iik7CiAJCWRpdi5pbm5lckhUTUwgPSBodG1sOwogCQlkb2N1bWVu dC5ib2R5LmFwcGVuZENoaWxkKCBkaXYgKTsKLQl9KTsKLQotCXRlc3QoICJmaXJzdENoaWxkIiwg ZnVuY3Rpb24oKXsKLQkJdmFyIG5vZGVzID0gZG9jdW1lbnQuYm9keS5jaGlsZE5vZGVzLCBubCA9 IG5vZGVzLmxlbmd0aDsKLQotCQlmb3IgKCB2YXIgaSA9IDA7IGkgPCBudW07IGkrKyApIHsKLQkJ CWZvciAoIHZhciBqID0gMDsgaiA8IG5sOyBqKysgKSB7Ci0JCQkJdmFyIGN1ciA9IG5vZGVzW2pd OwotCQkJCXdoaWxlICggY3VyICkKLQkJCQkJY3VyID0gY3VyLmZpcnN0Q2hpbGQ7Ci0JCQkJcmV0 ID0gY3VyOwotCQkJfQotCQl9Ci0JfSk7Ci0KLQl0ZXN0KCAibGFzdENoaWxkIiwgZnVuY3Rpb24o KXsKLQkJdmFyIG5vZGVzID0gZG9jdW1lbnQuYm9keS5jaGlsZE5vZGVzLCBubCA9IG5vZGVzLmxl bmd0aDsKLQotCQlmb3IgKCB2YXIgaSA9IDA7IGkgPCBudW07IGkrKyApIHsKLQkJCWZvciAoIHZh ciBqID0gMDsgaiA8IG5sOyBqKysgKSB7Ci0JCQkJdmFyIGN1ciA9IG5vZGVzW2pdOwotCQkJCXdo aWxlICggY3VyICkKLQkJCQkJY3VyID0gY3VyLmxhc3RDaGlsZDsKLQkJCQlyZXQgPSBjdXI7Ci0J CQl9Ci0JCX0KKyAgICBkb2N1bWVudC5ib2R5LmNwcEZpcnN0Q2hpbGQgPSBkb2N1bWVudC5ib2R5 LmZpcnN0Q2hpbGQ7CisgICAgZG9jdW1lbnQuYm9keS5qc0ZpcnN0Q2hpbGQgPSBtaXJyb3IoZG9j dW1lbnQuYm9keS5maXJzdENoaWxkKTsKIAl9KTsKIAogCXRlc3QoICJuZXh0U2libGluZyIsIGZ1 bmN0aW9uKCl7CiAJCWZvciAoIHZhciBpID0gMDsgaSA8IG51bSAqIDI7IGkrKyApIHsKLQkJCXZh ciBjdXIgPSBkb2N1bWVudC5ib2R5LmZpcnN0Q2hpbGQ7CisJCQl2YXIgY3VyID0gZG9jdW1lbnQu Ym9keS5qc0ZpcnN0Q2hpbGQ7IC8vIENoYW5nZSB0byBkb2N1bWVudC5ib2R5LmNwcEZpcnN0Q2hp bGQKIAkJCXdoaWxlICggY3VyICkKIAkJCQljdXIgPSBjdXIubmV4dFNpYmxpbmc7CiAJCQlyZXQg PSBjdXI7CkBAIC01NiwyMSArNzIsMTMgQEAgdmFyIGh0bWwgPSBkb2N1bWVudC5ib2R5LmlubmVy SFRNTDsKIAogCXRlc3QoICJwcmV2aW91c1NpYmxpbmciLCBmdW5jdGlvbigpewogCQlmb3IgKCB2 YXIgaSA9IDA7IGkgPCBudW0gKiAyOyBpKysgKSB7Ci0JCQl2YXIgY3VyID0gZG9jdW1lbnQuYm9k eS5sYXN0Q2hpbGQ7CisJCQl2YXIgY3VyID0gZG9jdW1lbnQuYm9keS5qc0ZpcnN0Q2hpbGQ7IC8v IENoYW5nZSB0byBkb2N1bWVudC5ib2R5LmNwcEZpcnN0Q2hpbGQKIAkJCXdoaWxlICggY3VyICkK IAkJCQljdXIgPSBjdXIucHJldmlvdXNTaWJsaW5nOwogCQkJcmV0ID0gY3VyOwogCQl9CiAJfSk7 CiAKLQl0ZXN0KCAiY2hpbGROb2RlcyIsIGZ1bmN0aW9uKCl7Ci0JCWZvciAoIHZhciBpID0gMDsg aSA8IG51bTsgaSsrICkgewotCQkJdmFyIG5vZGVzID0gZG9jdW1lbnQuYm9keS5jaGlsZE5vZGVz OwotCQkJZm9yICggdmFyIGogPSAwOyBqIDwgbm9kZXMubGVuZ3RoOyBqKysgKQotCQkJCXJldCA9 IG5vZGVzW2pdOwotCQl9Ci0JfSk7Ci0KIGVuZFRlc3QoKTsKIH07CiA8L3NjcmlwdD4K