Massive performance improvement#588
Closed
DannyReinhold wants to merge 7 commits intojknack:masterfrom
Closed
Conversation
added 5 commits
June 13, 2017 11:57
In earlier versions you could do something like this:
"{{#> myPartial}}{{#*inline 'myInline'}}Wow!!!{{/inline}}{{/myPartial}}"
And with a template myPartial.hbs like so
"{{> myInline}}"
you actually saw the "Wow!!!" text.
To provide this feature blocks have been evaluated even when they have not been rendered. With deeply nested partial blocks this could lead to severe performance issues.
With this commit, you still can call "myPatial" as in the example above.
But myPartial.hbs now has to evaluate the partial block explicitly like so:
"{{> @partial-block}}{{> myInline}}"
A tiny change that makes a huge performance difference.
…et to true, Handlebars gets *much* faster. The price: A little incompatibility.
…t pre evaluation of partial blocks
added 2 commits
June 16, 2017 11:55
Consider a scenaria such as this
---
{{#> test a=15}}
{{#> test}}
Hallo
{{/test}}
{{/test}}
{{#*inline 'test'}}
{{#if a}}
{{a}}
{{/if}}
{{> @partial-block}}
{{/inline}}
---
In Handlebars.java "a" was known in both executions of "test". The extended context containing the parameter "a" was inherited by the call to @partial-block.
In Handlebars.js this context is not inherited and therefor "a" is only known during the evaluation of the outer "test", not in the inner "test".
This patch modifies the behavior of Handlebars.java to become more compatible in this regard...
…id not improve the situation...
Owner
|
Going to manually add your changes (won't add all the code formatting changes). Thanks |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Handlebars.java evaluates partial blocks before the actual partials are evaluated and rendered. This is a feature to allow context modifications like so:
"{{#> myPartial}}{{#*inline 'myInline'}}Wow!!!{{/inline}}{{/myPartial}}"
And with a template myPartial.hbs like so
"{{> myInline}}"
you actually see the "Wow!!!" text.
This pre evaluation slows down the performance of handlebars.java significantly if deeply nested partial blocks are used. And I also think this is more or less unexpected behaviour (although it is compatible with handlebars.js).
With this commit you can control if this pre evaluation takes place or not. Without the pre evaluation the rendering process gets much faster!
You can still call "myPartial" as in the example above.
But myPartial.hbs now has to evaluate the partial block explicitly like so:
"{{> @partial-block}}{{> myInline}}"
A tiny change that makes a huge performance difference.
Of course there is a flag to control the behavior. If Handlebars::preEvaluatePartialBlocks is true (default) everythig is as you know it. If preEvaluatePartialBlocks is set to false, partial blocks are only evaluated (and rendered) when there is a {{> @partial-block}} and the rendering process is much faster.