Skip to content
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

{{#each}} is very slow #195

Closed
sstangl opened this issue Jan 1, 2018 · 6 comments
Closed

{{#each}} is very slow #195

sstangl opened this issue Jan 1, 2018 · 6 comments

Comments

@sstangl
Copy link

sstangl commented Jan 1, 2018

In a Rocket application, I have a Vec(Entry,Length) of size 1030, where Entry is a struct with 28 fields, and where Length is a struct with 4 fields.

Passing that Vec into the Template context, I attempted to render it into a table using {{#each}}:

      {{~#each entries~}}
        <tr>
          <td>TODO</td>
          <td>
            <a href="/u/{{this.1.username}}">{{this.1.name}}</a>
         ... and so on
      {{/each}}

Rendering this template with a --release build takes 8.5 seconds.

If instead I render the table as a String in Rust (but still pass the large Vec in the context), and then just include {{{the_string}}} in the Handlebars template, rendering takes 0.15 seconds.

I am not sure what part is taking a long time -- a perf recording shows that almost all time is spent in Vec/String allocation.

The Handlebars {{#each}} performance is acceptable with smaller Vecs. If the length is around 80, then the template renders in about 80ms. It appears to just have a very bad scaling factor.

@sunng87
Copy link
Owner

sunng87 commented Jan 2, 2018

I haven't look into the exact cause of the slowness. But currently we have a lot of data clone during rendering, which is known as key factor of this kind issues. I'm still attempting to rewrite some internal parts to avoid these clones.

For this issue, is it possible to provide me a JSON dump of your sample data?

@sstangl
Copy link
Author

sstangl commented Jan 2, 2018

I uploaded a JSON dump here: https://gist.github.com/sstangl/bcc7455493276b6360fd523a623698d5/raw/d1a16d34eb049585d282d24981ef5d080d58026d/sample-data.json

That is the contents of the entries vector for that one page that takes 8.5 seconds to load.

@sunng87
Copy link
Owner

sunng87 commented Jan 3, 2018

Thank you for providing me the dump!

@sunng87
Copy link
Owner

sunng87 commented Jan 13, 2018

@sstangl sorry for late. If you were using Rocket contrib 0.3.6, which uses handlebars 0.27, it should be a fixed issue with each loop #166 .

Update to rocket master you should be able to see improvements.

@sunng87
Copy link
Owner

sunng87 commented Jan 19, 2018

I will close this one for now. Feel free to reopen if you still have trouble with 0.28+ versions.

@sunng87 sunng87 closed this as completed Jan 19, 2018
@sstangl
Copy link
Author

sstangl commented Feb 19, 2018

I had not tried for a while, but with current Handlebars, the same page renders in ~4.6 seconds. Better than the 8.5 seconds originally, but still not usable.

Serde serialization of the whole data structure to a JSON string is extremely quick (~15ms), so I can work around it by just rendering into a big HTML string outside of the template.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants