Major performance issues

[pronvit]

Trying to investigate why Hexo is so slow, I found an interesting thing. Hexo always renders ALL files, even if no files are changed, and then rendering result for unchanged files is discarded.

Moreover, when rendering each file, it loads ejs templates and partials from the theme again and binds all the helpers, i.e. no template caching exists.

For example, for my not very bid site these two problems together lead to various ejs templates being processed 4500+ times and helpers being bound (

hexo/lib/theme/view.js

Line 78 in fc4ca63

locals[key] = _.bind(helpers[key], locals);

) 217000+ times (!) - always, even if no files are changed.

Any comments on this and plans to fix?

[leesei]

Thanks for your effort in pointing out the bottlenecks.
Indeed Hexo's rendering pipeline can be improved. Yet without documentation of how it works it's hard to have an overall optimization.

That said, Hexo do have fragment_cache. But some themes are not using it properly.

[SukkaW]

For a layout for article page, there might be only one partial but it will be used to render a lot of posts. Those posts have different locals. The layout itself may not change at all, but your post content or your config, which will affect locals, might change.

In order to use hexo's built-in helpers in the theme layout, all those helpers have to bind on each locals.

[stevenjoezhang]

I will close this issue because the cache is controlled by the Hexo theme. The theme developer decides which rendered content is cached and reused. For example, if every page has the same footer element, then the footer should be rendered faster using fragment_cache.