-
Notifications
You must be signed in to change notification settings - Fork 10
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
Improve build performance of docs site [HELP NEEDED] #44
Comments
This is about eating the dog food. We have a menu system, so use it. If the menu system does not do what you want, let us fix it. |
Please see my comments about the original intention in #45. I think Hugo's system works fine, but I had different goals in mind. I agree though that dogfooding is important. With the topic/title of this issue in mind, will this have a positive effect on the build? |
Yes. |
The main performance issue with the nav partial is the "range where .Site.Pages ...". We should fix this in Hugo by adding a cache to this and similar template funcs, but even then I would say that the Hugo Docs site SHOULD use the built-in menu system, even if we loose some functionality. |
Did a quick hack to show (I think) timings for all partial templates. These number are CPU time. Due to concurrency, we have multiple jobs and timers running at the same time. So, the site-nav clocks in at 37s, which is 3x the total build time of 11s (yes, my old machine is slow).
|
Bothers me that you can't emoji-response on mobile GH. Yowzer, @moorereason Slow machine or not, no reason for this single partial to rebuild at almost 3 times the speed of the entire Smashing site. I will refactor to use menus. The current Hugo site has next/prev set manually in the front matter, but I think this is better taken care of at the template level so that authors can focus just on the content piece. Thoughts? |
Yes, that should not be in the content files. |
Ryan, this sounds similar to your desire to sort menu children by a field of the child pages. Hence, your use of the YAML data file. Are you asking for the same feature for Next/Prev (or, more probably, NextInSection/PrevInSection)? |
Not entirely, although you're a bit of a mind-reader since I was thinking about a feature request for something a la I'm referring to the front matter that is in the content files of the current docs site and whether you guys think this is worthwhile for me to consider as part of this refactoring. I think it asks a bit too much of the author to set next/prev manually, especially in longer sections, and eventuates in sloppy nav and tethers content metadata to presentation. But both of you also have much more experience with the PRs for the docs thus far. Honestly, I've never built anything with Hugo's menu feature, so this is a good learning opportunity and also why I can't fully weigh in on any shortcomings/strengths of the feature. That said, if we think it will improve the perf on the docs build for me to change this to the menu, I'm all for it. |
Why do you need so many markdownify functions?
|
I should report this here before anyone spends time on the docs code exist now. We're building a new theme for the docs. Here are the benchmarks for old and new: Old (Hugo Docs Concept) Theme
New Theme
|
Seeing as @budparr 's theme has shown considerable improvements for site build times, I'm going to go ahead and close this. |
@digitalcraftsman @moorereason @bep @budparr
Here's on my mid-2012 Macbook Pro, 500gb SSD, 2.6 GHz Intel Core i7, 8 GB 1600 MHz DDR3:
My typical results running the local server:
And when I switch
{{- partial "site-navigation.html" . -}}
inbaseof.html
to{{- partialCached "site-navigation.html" . -}}
:I take this to mean that the navigation is the biggest offender, but I'm not sure how to cache/variant this in a way that still gets the desired output w/r/t active classes, etc. I am not using Hugo menus and instead pulling this info from this data file.
The text was updated successfully, but these errors were encountered: