-
-
Notifications
You must be signed in to change notification settings - Fork 143
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
Template rendering is very slow for large data #166
Comments
Thank you for reporting @bruceg , I will look into this issue this weekend. |
It happens with both 0.27.0 and git master |
Signed-off-by: Ning Sun <[email protected]>
Signed-off-by: Ning Sun <[email protected]>
Signed-off-by: Ning Sun <[email protected]>
Just confirmed this performance issue was introduced in 0.27, which clones Based on bench code in b2354be 0.27 0.26.2 @bruceg you can use handlebars 0.26.2 for now. And I'll find a solution to improve while keeping the new features in 0.27. |
Signed-off-by: Ning Sun <[email protected]>
Fixed in 0.28.0 |
When rendering a template over a large vec (say, more than 1,000 items), handlebars-rust takes a very large amount of CPU time. Worse, extra data within the result (that may not be rendered) increases the time taken.
This sample program demonstrates the problem: https://gist.github.com/bruceg/410deb60468940c0b40a52814c2a2896 (run with two parameters, first is number of real rows, second is number of "dummy" rows that are not rendered). The run time is approximately O(N*(N*D)) where N is the number of rows to output, and D is the size of the dummy array. Doubling the number of rows produces a roughly four times increase in the total run time.
My guess would be the whole data is being copied (cloned) once per row somewhere. strace shows many calls to madvise(ADDR, SIZE, MADV_DONTNEED) between output writes, which seems to indicate large chunks of data being freed by the allocator.
The text was updated successfully, but these errors were encountered: