-
Notifications
You must be signed in to change notification settings - Fork 479
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
Extremely slow render #496
Comments
Your timing looks right to me-- however, it's the compiling step that takes much longer for Dust templates. Rendering time is negligible.
The nature of Dust means that there's a little more to its compilation logic, since one template might be composed of many blocks. That said, compilation isn't something that should be happening often-- if you're running Dust as part of a webserver, it will cache your compiled templates, and if you're running Dust as part of a build process, it's unlikely to be the bottleneck step. In general, your strategy should be to serve up compiled templates, and Dust is very fast at rendering a compiled template. |
@sethkinast - thanks for verifying that. Yeah, I understand your point completely & I found that once Dust had actually generated the JS, the actual rendering was almost identical time-wise with handlebars... ... but, I'm creating a tool that needs to re-process files when they change, and for this use-case dust is just going to be too slow. |
The other thing that might be worth considering is that Dust is much better at small templates, and composing those templates into larger pages. The compile speed grows non-linearly as your template size increases. If you're regularly compiling these really big templates, then yeah-- Dust is unfortunately just not oriented towards your needs. But if you're only changing sections, you might consider recompiling only that section. Additionally, if you have large amounts of text in a template, that's really data-- perhaps it would be helpful to move the data into the context JSON, and out of the template? Then Dust doesn't have to worry about it. |
Okay, don't count us out quite yet! Check out #497 -- I've done a little investigation and I think we can provide you with the performance you need. |
OMG that would be a dream come true! My project was inspired by how cool DustJS is & I've been on a downer thinking I was going to have to use Handlebars. |
Also worth noting that I'm not looking for a speed match, just something a lot closer than 12x :) |
I've now found another issue with how I'm trying to use this. If you attempt to render the file mentioned above, after disabling white-space suppression, you end up with var dust = require("dustjs-helpers");
var fs = require("fs");
var md = fs.readFileSync("./docs/index.md", "utf-8");
dust.optimizers.format = function (ctx, node) {
return node;
};
dust.loadSource(dust.compile(md, "test"));
dust.render("test", {}, function (err, out) {
// RangeError: Maximum call stack size exceeded
}); |
Resolved by #497. |
I'm trying to use Dust as the templating language for a new project, but I've run into some huge performance problems & I'm wondering if i'm using the library incorrectly.
Running the source code of this file: https://gist.github.com/shakyShane/52a7db0cbcf5bdb5aade through handlebars takes < 100ms.
But if I put that same file through dust, it takes approx 1200ms...
Is Handlebars really 12x faster? Surely there's somthing I've missed here..
Thanks for any help.
The text was updated successfully, but these errors were encountered: