Option for Faster Node Rendering & Creation

[Ariesto]

Allow the option to create nodes faster. Creating an issue to track the various ways to speed up the rendering of 10,000 node children within a single folder.

I created a sample and will upload it. Essentially, it adds an option "renderNodeEvents" that the user can set to FALSE. By disabling these two event calls the speed increases dramatically.

My proposed code changes have the following benchmark scores in Firefox:

Original: 5091 ms
Proposed: 1650 ms
i.e. 68% faster

Before closing this issue, I would like to have a discussion about how the nodeRender: function() works. I originally tried to improve the generation by modifying this method. I feel like there is a way to use Document Fragments to speedup the generation. I wasn't 100% sure that the current method adds the entire tree to the DOM in one addition (ie if the deep=true). It seems like it might add each completed LI to the DOM (which could happen several times).

Three references:
http://ejohn.org/blog/dom-documentfragments/
https://developers.google.com/speed/articles/javascript-dom
http://jsperf.com/documentfragmentui

[mar10]

Thanks for bringing this up, I did not expect the jQueryUI widget _trigger
method to be that slow.

Performance is always an important issue, and there are already some benchmarks
http://wwwendt.de/tech/fancytree/test/unit/test-bench.html
I added a test case for _trigger:

10000 createNode DOM events (widget._trigger()) took 294 milliseconds, 34,014 items/sec
10000 createNode callback events (options.createNode() defined) took 5 milliseconds, 2,000,000 items/sec
10000 createNode callback events (options.createNode() undefined) took 4 milliseconds, 2,500,000 items/sec

I think I will replace the _trigger call with a direct function call options.createNode,
as the execution time becomes neglectable.
The drawback is, that no additional DOM event is fired that a user can bind("fancytreecreatenode") to.

As to your other remarks:
The render function should add the elements to the DOM in one final step, hence the comment

// Finally add the whole structure to the DOM, so the browser can render

at least that was the plan. I will check again.

The table extension
already uses createDocumentFragment. Maybe that will also help to improve performance for the standard renderer.