Dear Toni, I had a very short look into your benchmark (sorry, I just don't have the time currently for an exhaustive look). On my laptop I was able to reproduce your numbers: 10k DOM creations: ~80ms 10k DOM modifications: ~40ms (25ms - 55ms) Seems, my (very new) laptop is a little faster, but it's in the same range. I saw that the JS modification in the test were just calling a function that sets the data of the object (something the JS engine has inlined quickly). To make it a little better comparable, I added a callback that sums up the ids. The DOM mutation events are clustered and scheduled in a separate phase: 10k DOM modifications: ~40ms + 6ms in callback 10k JS modifications: ~19ms Now we have _2.5x_ difference! Of course these results are just based on one iteration and using the very fuzzy Date.now() mechanism (just a tip: There is window.performance to do better performance measurements). I don't want to put into question that using specialized data structures in JavaScript is faster than using a generic general purpose data structure like the DOM. But comparing is very hard since the variance is very high, depending on how well JS can optimize, which JS engine you use and which platform you use (for instance on mobiles, the JS performance is still very bad). The DOM is meant as in interface to the user. That's how we designed XML3D. All medium-range modification (a few hundereds per frame) are okay. One must not forget that users will use jQuery etc, which can -- used the wrong way -- slow down the whole application (not only for 3D content). For all other operations, we have concept like Xflow, where the calculation is hidden behind the DOM interface. Also the rendering is also hidden behind the DOM structure. We even have our own memory management to get a better JS performance. Thus it really depends on the use case and the design of the DOM interface. The proposed benchmark might be too simple and one should be carefully with statements... Best regards, Kristian > Ok so here is info about the DOM manipulation performance test that we > recently started working on. I totally agree with the idea of having > small targeted groups for specific topics, such as this 3d web client > architecture. However as those don't exist yet let's use this list now > for the first communications before the conf call that's being > scheduled for this week. > > This benchmark is really simple and by no means fancy at this point > but already gives some information. 'Massive' in the email subject > refers to the fact that it can do a massive amount of DOM > manipulations, not that the test code would be massive at all :) > > The code and little documentation is available at: > https://github.com/playsign/wex-experiments/tree/master/domBenchmark > > The rationale is that in the current native realXtend implementation > in Tundra SDK we have a similar mechanism: the core scene has all the > data is in entity-attributes, and for example incoming network > messages that move objects are handled so that the net part modifies > that scene, which the renderer observes and updates the graphics > engine scene accordingly. > > In the FI-WARE goals and plans, and in the declarative 3d web movement > in general, there are good reasons for having all the data in the DOM > -- for example being able to use the browser debugger to see and > modify the values. We have the same in native Tundra SDK's scene & > entity editor GUIs. > > I drew a first sketch of an architecture diagram about how this could > work in the browser client, in a minimally modified WebTundra first > where using a JS array for the scene data is just switched to using > the DOM document instead: > https://rawgithub.com/realXtend/doc/master/dom/rexdom.svg (in case > someone wants to edit it, the source is at > https://github.com/realXtend/doc/tree/master/dom - I used Inkscape > where SVG is the native format). > > To examine the feasibility of this design I wanted to know how it > performs. We don't have conclusive analysis nor any final verdict yet. > We test with quite large numbers because we can have quite a lot > happening in the scenes -- at least tens or hundreds of constantly > moving objects etc. In this design every change in every object > position would go via the DOM. > > To contrast, we have the similar mechnism implemented in pure JS - > just an array with the data and a reference to the observing callback > function. It is much simpler in functionality than what the DOM and > Mutation Observers provide -- can be perhaps considered as an upper > bound how fast an optimized solution could work. So not a fair comparison. > > Some early figures: > > Creating DOM elements is quite fast, I now created 10k elements in > 0.136 seconds. > > Manipulating is quite fast too, 10k attribute modifications were made > in 84ms for me now. > > Erno did a little better benchmarking with a 100 repeated runs, both > for the DOM using and pure JS versions. His figures are on the > benchmark projects website but I paste to here too: > > "running the test for 10k elements 100 times in a row, the pure-js > version takes 19 ms. The DOM version of same takes 4700 ms. So a 250x > difference." > > We are aware that this is a microbenchmark with all kinds of > fallacies, can be improved if real benchmarking is necessary. > > But now I think the first question is: what are the real application > requirements? How much DOM manipulations do we really need? > > We talked a bit about that and I think we can construct a few > scenarios for that. Then we can calculate whether the performance is > ok. I wrote that question to the stub overall doc that plan to > continue in https://github.com/realXtend/doc/tree/master/dom > > This whole track was overridden a bit by the campus party preparations > recently but I think now is good time to continue. > > I hope this clarified the situation, am sorry for the confusion that > the quick '300x diff' pre-info during the weekend caused.. And to make > it clear: we haven't done this with a real 3d client or networking or > anything like that but decided to benchmark first in isolation. > > About the performance difference, we suspect that it is due to the > internal machinery that the browser executes for every DOM change, and > possibly also something in the C++ <-> JS interfacing. I looked a bit > and found that to optimize large DOM manipulations web folks batch > e.g. element creations etc. and don't do them individually. > > Do ask for any further info, and please bear with us and the early & > bit cumbersome to use test case (we mostly just made it for ourselves > for now at least). > > Cheers, > ~Toni > > > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-miwi -- _______________________________________________________________________________ Kristian Sons Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, DFKI Agenten und Simulierte Realität Campus, Geb. D 3 2, Raum 0.77 66123 Saarbrücken, Germany Phone: +49 681 85775-3833 Phone: +49 681 302-3833 Fax: +49 681 85775--2235 kristian.sons at dfki.de http://www.xml3d.org Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _______________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20130902/35920030/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy