Open tgross opened 5 years ago
bridgetkromhout
commented
5 years ago This is super exciting. Thanks for taking the time to test performance and give us such a detailed analysis, @tgross! This is going to help local development, but I also suspect it might help with our netlify build times too.
mattstratton
commented
5 years ago I bet that I’m doing something similar with the program page of looping through all the talks, etc, so it probably can be made much better!
bridgetkromhout
commented
5 years ago Uh-oh! @adrianmoisey noticed that unfortunately the change in https://github.com/devopsdays/devopsdays-theme/pull/644 had the unintended side effect of making it so when one speaker has two talks at a given event, only one of them shows up. Example: https://www.devopsdays.org/events/2018-portland/speakers/heidi-waterhouse/ - she has an ignite as well, and it shows up if I revert the changes to the speaker page that were added in this PR:
Checking in with @tgross to see if it would be trivial for him to adjust that, or if in the interests of "oops, this affects an ongoing event today" I should revert those specific changes and we can revisit?
Heidi is a developer advocate with LaunchDarkly. She delights in working at the intersection of usability, risk reduction, and cutting-edge technology. One of her favorite hobbies is talking to developers about things they already knew but had never thought of that way before. She sews all her conference dresses so that she’s sure there is a pocket for the mic.
tgross
commented
5 years ago I would revert.
The change I made relies on the URL construction to query for the correct page for the talk, but this turns out to be an incorrect assumption when there's multiple talks by the same speaker because (obviously) the two talks don't have the same URL. I'll need a bit of time to mess around with a more reliable query there, so I would recommend reverting in the meantime.
bridgetkromhout
commented
5 years ago Cool, thanks. Indeed, URL will vary - it can and will differ (of course) but also it can be a workshop name or any arbitrary string not containing speaker name.
Should I revert the whole PR or just the speaker page bit, do you think?
tgross
commented
5 years ago It's easier for me to land the fix later if you only revert the speaker page bit but probably easier for you to revert the whole commit. So whichever you want :grinning:
Using the
hugo --stepAnalysisoption we'll find that, as we'd expect, the biggest amount of time is being spent in the "render and write pages" steps (~60 seconds overall compared to millseconds for the other steps).We can use
hugo --templateMetricsto break this down. Running this a couple times to make sure any disk cache is warmed up (although it didn't really make a difference), I get the following:The immediate low-hanging fruit here is the
partials/footer.htmlwhich is taking up ~60s of CPU time all by itself. The footer has nothing specific to a page on it, so we can use thepartialCachedfunction on it. Because this is called in every page this ends up saving us almost half our rendering time right off the bat.After caching the footer:
That saves us a lot!
Some other areas of improvement to be made:
The talk and speaker pages are unique so we can't avoid rendering these a lot. But they are relatively expensive so if we can make some improvements on these it'll bring down overall time.
A look at the
talk/single.htmltemplate shows that in order to find data about the speaker we're looping over all the speakers that have ever spoken! If instead we use the.GetPage(with proper nil-testing), we can avoid doing all that work.After making that fix:
We do the same thing for the speaker page, where we iterate over all the talks to find the just the ones they're giving at that event. After making that fix for speaker pages too:
I've opened a PR with these three big-ticket items.
A future area to examine is the program page:
The program page is very expensive on an individual basis. So optmizing that would have a big impact.
Also for future work, smaller but harder-fought wins could be found in some of the other partials:
Probably no way around rendering most of these for each page, but each renders very quickly. If we could extract cacheable partials from these that might reduce some time here but we'd want to test each change.
cc @bridgetkromhout @mattstratton