[Fiware-miwi] EntSys: domPerf revisited & net sync work

[Toni Alatalo]

News from Entity System work, on the 1. DOM integration investigation & 2. sync GE work fronts:

1. DOM performance revisited:

In the xml3d.js code reading that I did last weekend & in the discussions in the Monday meet one observation was that in the xml3d.js model of DOM integration there is an optimization mechanism for attribute access. But the creation of new elements goes directly to the document object. Philipp suggested that we’d use the DOM for the scenes so we returned to investigate it again this week.

In the old naive DOM perf test we did early on there is both element creation & attribute modification tests. Earlier the focus was mostly on the attribute modification.

In large scenes we can however get a lot of element creation too, at startup or when large changes happen (e.g. almost the whole scene contents is switched to something else on the fly). Earlier we saw that with a quite large number of 10k elements that was not too horrible(some seconds). But on Tue I tested with 100k(*) elements and it seemed to get slower exponentially — it took several minutes.

The good news is that the usual DOM usage optimization worked: adding the new elements to a first unattached parent element which is only added to document.body as the last step reduced the time from ~4min -> 0.86secs. I took that trick from https://developers.google.com/speed/articles/javascript-dom . We were not sure whether these html-reflow avoiding optimizations affect with the invisible, unknown-to-browser elements but apparently they do. The last step to add the whole subtree of 100k elements to document.body doesn’t cost much: skipping that reduced the time from 0.86s -> 0.80s only. This optimization is now on in the microbenchmark code at https://github.com/playsign/wex-experiments/tree/master/domBenchmark (the readme doc there is not updated for this change yet though, only the code).

This rises the question: when should the 3d scene added to the document? As we can get huge changes to it via net sync or from application logic at any later point as well: for example a city planning app can say: ‘switch city area X from future plan A to alternative B’

Proposal: Keep the 3d scene tree of DOM elements outside the document by default (in the typical realXtend usage). Add it to the document.body on demand: when the user/dev wants to see it using view-source or a browser debugger, or for some other reason. It is quick to do so not a problem, needs some way to trigger it though. Otherwise it’s off the doc so the manipulation stays efficient. It does not affect the API (much), they’d still be normal DOM elements etc. One thing we have to check is whether DOM mutation observers etc. all work correctly outside the document.body too. Loading the scene from a HTML doc, typical xml3d style, can still work too. If we for example have a getter func for the root node it doesn’t make a diff for application code whether the tree is in the document.body or not.

2. Sync GE:

Lasse is now progressing with the Sync GE work and needs some place where to put&get the data from&for the network messages. He figured (on Tue/Wed) that the raw DOM does not suffice as there is no type information for the attributes. He’s now using Chiru-Webclient’s code for that, there is a typed Attribute object (similar to native Tundra). Changing that to whatever becomes the final system is not a big deal, he just needs something now to develop & verify the networking. But the type information is required and it’s not yet clear exactly how we should have that.

So this is where we are now with the entity system work — next week hopefully takes us much further again. Comments & insights & suggestions etc. are welcome. One thing I’ll do soon is to check again xml3d.js’s JS xml3dobject / attribute code to see whether that could work for Sync (& Interface Designer).

~Toni

(*) 100k elements may seem like much but there the point is that for a single 3d scene object (== entity) we get multiple xml elements, even 5-10, as there is one for each reX component in the xml3d style (== normal xml style). As TXML it would be even much more as there’s an xml element for every *attribute* too. So the rationale is a big complex scene with 10k entities, avg 10 components each -> 100k xml elements as xml3d (might be a million as txml :)