-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1st patch is slow #8
Comments
2x for the initial patch seems a bit high - guess it really depends on what your templates are / do (guess your templates are precompiled, right?). Said that, I don't think there's much of an advantage with just about any dom renderers vs native parsing of HTML strings (e.g. via |
Another thing worth mentioning here (despite being a fairly obvious one): idom |
I had the same conclusion. And yes I'm using a Like you said, it's really dom renderers vs native parsing. x2 seems a lot but we are talking about milliseconds here, like 4ms vs 2ms. This is not much, but multiply by hundreds of views / components this is quite a slow down for the 1st render / paint of a whole web application. The only solution I can think of would be server rendering and patching over existing DOM... |
Guess it really depends if there is really a performance issue that perceivably slows things down. |
In modern browsers seems that this not true anymore. I read that sometimes ago, although i don't remember exactly where. But there are some facts that points toward that. The main virtual dom implementations (React, Snabbdom) patch the elements in place instead of detaching or using documentFragment. This perf https://jsperf.com/document-fragment-vs-innerhtml-vs-looped-appendchild directly appending is little faster both in chrome 61 and Firefox 57 |
Now I'm confused... appending is 2.75% faster than innerHTML in this benchmark (on my computer) but my benchmark between innerHTML and idom patch is 100% (sometimes more, again on my computer) slower and I though idom 1st patch was merely kind of appending (because I'm pre-compiled) |
The higher cost of first render when using virtual dom approaches is expected. It has to build the virtual tree than apply all dom operations. On subsequent render it also has to build the entire virtual tree but only do a few dom operations. incremental-dom is a kind of virtual dom, the difference is that instead of building a separate tree, it stores the virtual info as an expando property in the html element in the first render. Regarding incremental-dom performance, in this comment google/incremental-dom#214 (comment) , there's a mention of "our slowdown" without explaining much. Maybe @jridgewell, that worked in performance, can clarify the supposed idom performance issues. |
@JSteunou This is important because incremental-bars does everything in one pass unlike traditional string template that first needs to build the string than set innerHTML Given this info, i would benchmark a template with a non trivial amount of HTML elements. This could show some difference come from the string concatenation and posterior parsing by the browser |
Yep, I measured inside the render logic of a Marionette View with both precompiled templates, both just before just after rendering appending / patching logic. But my template was pretty thin, one element with 3 children. Worth trying with a bigger and more complex structure |
This might be a question for the idom team but maybe you will have some answers.
Playing with some performance measure on a quite simple view, my 1st render using
patch
is in average 2.5x slower than usinginnerHTML
with default Handlebars text output. Consecutivepatch
with some text change are 2x faster. Is this possible to get the better of both?The text was updated successfully, but these errors were encountered: