Open lyind opened 1 month ago
While Go templates isn't the fastest on earth, I don't think your conclusion above is correct.
In all the examples of "slow Hugo sites" I have seen (and I have seen one), it always boils down to doing too much work.
Complex themes (e.g. docsy), combined with a decent amount of pages, do indeed highlight the limits of Hugo's current architecture, in particular around template execution.
Yes:
--renderSegments
might allow us to save time that way. (Assuming we'd be willing to store/cache build output in some way between builds, which isn't great for reproducibility.)However:
I'd not request such optimizations from projects in incubating or prototype phase, but mature products with many users, like Hugo, could indeed profit.
Summary
As part of a sustainability initiative, I found that Hugo builds for complex themes (e.g. Docsy in my case) can take longer and consume more CPU cycles than expected.
Expectation
Hugo needs single-digit milliseconds to render an individual page:![grafik](https://github.com/user-attachments/assets/2c981f0e-97fd-4feb-8249-cc71f9dee265)
Observed Condition
Hugo needs (133685ms / 1707) = ~78ms per page:
Analysis
Some profiling, tracing and experimentation lead to the following result:
fstatat
, which could maybe be optimized/avoided) just consumes ~1s of our total ~120s runtime. This is less than 1%. (!)Go routine traced execution time top 5:![grafik](https://github.com/user-attachments/assets/6a6e5de7-b966-4fca-b297-81523dc7e6c3)
pprof profiles:
![grafik](https://github.com/user-attachments/assets/6740a743-9f6e-4ea4-9bfb-dfc3739a93ef)
Proposed Action