Opened 12 years ago
Closed 8 years ago
#8695 closed enhancement (fixed)
let the markup explicitly specify terminal dojoType nodes
Reported by: | lipik | Owned by: | bill |
---|---|---|---|
Priority: | low | Milestone: | 1.9 |
Component: | Parser | Version: | 1.3.0b1 |
Keywords: | parser, speedup, enhancement needsreview | Cc: | |
Blocked By: | Blocking: |
Description
Hi, I have a suggestion to speed up dojo.parser, without extensive changes. The idea is simple: like dojoType, introduce another attribute, dojoTerminal, which can be true or false. If this is set to true, it is hint to the parser that there are no elements with a dojoType attribute under this branch, so the parser (or the initial query) can terminate the traversal early. I believe this feature, judiciously utilized, will significantly speed up parsing on complicated pages and would be fully backward compatible.
The implementation of this would be simple - probably just a matter of rewriting a query string.
Change History (7)
comment:1 Changed 12 years ago by
Milestone: | tbd → 2.0 |
---|
comment:2 Changed 12 years ago by
Well, I am assuming that the selector engine (either browser native, or ACME) would implicitly optimize its parse traversal with a query-string like so:
"*[dojoType] *:not([dojoTerminal])"
as against
"*[dojoType]"
I will try to run some tests and attach them here.
Another idea might be to detect the type of the second argument to dojo.parser.parse, and if it happens to be an array, assume that it is the complete list of nodes that the user wants to be parsed, and there is no need for a DOM traversal.
comment:3 Changed 10 years ago by
Summary: | Enhancement suggestion: let the markup explicitly specify terminal dojoType nodes → let the markup explicitly specify terminal dojoType nodes |
---|
For 1.5 (or was it 1.6?) I added a _stopParser flag to widgets; if it's there then the parser doesn't parse descendants of that widget. Not quite the same though.
Parser is no longer using dojo.query(), it's running top-down, which would make this enhancement fairly simple.
comment:4 Changed 9 years ago by
Keywords: | needsreview added |
---|---|
Priority: | high → low |
bill, i think _stopParser
might be enough to close this ticket. is there some other reason to keep it open?
comment:5 Changed 9 years ago by
Well, _stopParser is on the widget prototype whereas this ticket is about a flag in the markup (ie, index.html file) itself.
I guess I was leaving the ticket open to see how things go with the async-parser changes. If we keep the top-down parser then I'll implement this, otherwise close it as wontfix.
comment:6 Changed 8 years ago by
I personally don't like the terminate parser... the idea of having a customisable CSS selector to select the nodes (which I am proposing in the 2.0 parser) would allow this to work in this scenario (plus a lot of others).
I suggest we close this.
comment:7 Changed 8 years ago by
Milestone: | 2.0 → 1.9 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Actually I needed to implement this to get server side instantiation working correctly. It's in [30789]. It works by putting the stopParser property (not attribute) on any node.
Hi Lipik,
Yes I've thought about stuff like this for 2.0, plus doing deferred parsing, ex: waiting until a tab pane is shown before parsing it.
Something like dojoTerminal is hard w/the current parser architecture because it finds nodes with dojo.query(), which just returns a flat list of nodes containing dojoType, with no regard to hierarchy.... so would probably have to give up on using dojo.query().