Side navigation
#8109 closed enhancement (invalid)
Opened February 01, 2011 12:23AM UTC
Closed June 11, 2012 06:29PM UTC
Meta: jQuery.tmpl Performance Issues
Reported by: | rwaldron | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | 1.next |
Component: | templates | Version: | 1.5 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Opening up discussion to document the improvement of jQuery.tmpl performance, as illustrated here:
Attachments (0)
Change History (10)
Changed February 01, 2011 12:25AM UTC by comment:1
component: | unfiled → templates |
---|---|
description: | Opening up discussion to document the improvement of jQuery.tmpl performance, as illustrated here: \ \ http://jsperf.com/template-test → Opening up discussion to document the improvement of jQuery.tmpl performance, as illustrated here: \ \ http://jsperf.com/dom-vs-innerhtml-based-templating/50 |
priority: | undecided → high |
Changed February 01, 2011 12:25AM UTC by comment:2
status: | new → open |
---|
Changed February 01, 2011 12:40AM UTC by comment:3
description: | Opening up discussion to document the improvement of jQuery.tmpl performance, as illustrated here: \ \ http://jsperf.com/dom-vs-innerhtml-based-templating/50 → Opening up discussion to document the improvement of jQuery.tmpl performance, as illustrated here: \ \ http://jsperf.com/dom-vs-innerhtml-based-templating/70 |
---|
Changed February 01, 2011 01:52AM UTC by comment:4
Perf is important, but perf comparisons are sometimes incorrect.
The tests on the link are comparing how long each engine takes to render an HTML string. But for jQuery templates, they are using calling $.tmpl(template, data)- many times, which does not render an HTML string. It builds a jQuery object around a document fragment containing the rendered HTML ready for chaining with .appendTo. To use this without calling appendTo makes no sense, and will not perform well. It does much more than build an HTML string.
One of the goals of Beta2, planned for April, is to provide an API to allow you just to render an HTML string, if that is all you want. You can then innerHTML or .html(), for example to insert it. You can also render as a string on the server, and render that to the Response, for initial rendering. But there is also an activation step, which runs by default, and gives you tmplItem, and opens the way to all the interactive applications, if your app is not just read-only rendering. You can choose whether you want activation or not.
The current implementation uses a mix of string concatenation and document
fragment instantiation, and does not provide an option for just rendering to a string. That has history going all the way back to the first prototype which John created, which this evolved from. See this issue, for related discussion:
https://github.com/jquery/jquery-tmpl/issues/closed#issue/4. It links also to a discussion here: http://rileydutton.com/post/1303173205/jquery-templates-vs-jqote-2-a-followup-a-k-a-the%20%20
Changed February 15, 2011 08:15PM UTC by comment:5
_comment0: | I have added a revision here to the perf comparison benchmark here: http://jsperf.com/dom-vs-innerhtml-based-templating/83, to correct some errors in the tests. The result is the jQuery Templates come out 12 times faster than the previous (misleading) results. The results are better than some of the other template engines, but fall quite a lot short of the fastest ones. That said, jQuery Templates does much more than those other fastest ones, (which are basically stripped down to minimal features for read-only rendering, no detection of functions, undefined, etc., with perf being in most cases their primary goal, I beleive.) \ \ I think that the design changes in the pipeline for Beta2 will bring some signficant perf improvement for jQuery Templates, when used in read-only scenarios... → 1297813130632601 |
---|
I have added a revision to the perf comparison benchmark here: http://jsperf.com/dom-vs-innerhtml-based-templating/83, to correct some errors in the tests. The result is the jQuery Templates come out 12 times faster than the previous (misleading) results. The results are better than some of the other template engines, but fall quite a lot short of the fastest ones. That said, jQuery Templates does much more than those other fastest ones, (which are basically stripped down to minimal features for read-only rendering, no detection of functions, undefined, etc., with perf being in most cases their primary goal, I believe.)
I think that the design changes in the pipeline for Beta2 will bring some signficant perf improvement for jQuery Templates, when used in read-only scenarios...
Changed April 17, 2011 11:20PM UTC by comment:6
resolution: | → invalid |
---|---|
status: | open → closed |
This should be moved over to the jQuery Templates bug tracker.
Changed April 18, 2011 12:02AM UTC by comment:7
Yes, this corresponds to https://github.com/jquery/jquery-tmpl/issues/4
Changed June 11, 2012 06:26PM UTC by comment:8
Changed June 11, 2012 06:29PM UTC by comment:9
resolution: | fixed |
---|---|
status: | closed → reopened |
Ignore the message above, should have referenced #7109.
Changed June 11, 2012 06:29PM UTC by comment:10
resolution: | → invalid |
---|---|
status: | reopened → closed |
This is not a jQuery Core ticket.