````
│ stash.bench │ perf-v146.bench │
│ sec/op │ sec/op vs base │
LookupPartial-10 248.00n ± 0% 14.75n ± 2% -94.05% (p=0.002 n=6)
│ stash.bench │ perf-v146.bench │
│ B/op │ B/op vs base │
LookupPartial-10 48.00 ± 0% 0.00 ± 0% -100.00% (p=0.002 n=6)
│ stash.bench │ perf-v146.bench │
│ allocs/op │ allocs/op vs base │
LookupPartial-10 3.000 ± 0% 0.000 ± 0% -100.00% (p=0.002 n=6)
```
THe speedup above assumes reuse of the same partials over and over again, which I think is not uncommon.
This commits also adds some more lookup benchmarks. The current output of these on my MacBook looks decent:
```
BenchmarkLookupPagesLayout/Single_root-10 3031562 395.5 ns/op 0 B/op 0 allocs/op
BenchmarkLookupPagesLayout/Single_sub_folder-10 2515915 480.9 ns/op 0 B/op 0 allocs/op
BenchmarkLookupPartial-10 84808112 14.13 ns/op 0 B/op 0 allocs/op
BenchmarkLookupShortcode/toplevelpage-10 8111779 148.2 ns/op 0 B/op 0 allocs/op
BenchmarkLookupShortcode/nestedpage-10 8088183 148.6 ns/op 0 B/op 0 allocs/op
```
Note that in the above the partial lookups are cahced, the others not (they are harder to cache because of the page path).
Closes#13571
This commit also
* Unexport all internal state in TemplateInfo.
* Make the dispatcher keys used for passing context.Context into uint8 from string to save memory allocations.
Co-authored-by: Joe Mooring <joe@mooring.com>
Updates #13571
This should:
1. Fix some (rare) tiebreaker issues when sorting pages from multiple content adapters.
2. Improve the sorting for pages without a backing file.
These were added to the page meta object when we implemented "pages from data", but were not meant to be used in front matter.
That is not supported, so we might as well add validation.
Fixes#12484
This is an empty struct for now, but we will most likely expand on that.
```
[contentTypes]
[contentTypes.'text/markdown']
```
The above means that only Markdown will be considered a content type. E.g. HTML will be treated as plain text.
Fixes#12274
This is a follow up to db28695ff5 -- that commit dropped the cache items evicted in the LRU process. This was done as performance optimization for large Hugo sites.
That made much sense, but now there's a slight chance that we miss out on a change when rebuilding.
This commit fixes this by applying the same logic to the evicted items as if they were still in the cache. This should preserve the performance gains in db28695ff5 and close the hole for the possible false negatives.
Two issues:
1. Fixe potential edit-loop in server/watch mode (see below)
2. Drain the cache eviction stack before we start calculating the change set. This should allow more fine grained rebuilds for bigger sites and/or in low memory situations.
The fix in 6c68142cc1 wasn't really fixing the complete problem.
In Hugo we have some steps that takes more time than others, one example being CSS building with TailwindCSS.
The symptom here is that sometimes when you:
1. Edit content or templates that does not trigger a CSS rebuild => Snappy rebuild.
2. Edit stylesheet or add a CSS class to template that triggers a CSS rebuild => relatively slow rebuild (expected)
3. Then back to content editing or template edits that should not trigger a CSS rebuild => relatively slow rebuild (not expected)
This commit fixes this by pulling the dynacache GC step up and merge it with the cache buster step.
Fixes#13316
This can lead to stale aliases when rebuilding, but that's a trade-off we need to take for snappier rebuilds on bigger sites.
Note that it should be possible to detect alias changes, but I'm not sure it's worth it.
The failing test case here is
* A custom search output format defined on the home page, marked as `noAlternative` and not `permalinkable`
* In fast render mode, when making a change to a data source for that search output format, the JSON file was not refreshed.
There are variants of the above, but the gist of it is:
* The change set was correctly determined, but since the search JSON file was not in the recently visited browser stack, we skipped rendering it.
Running with `hugo server --disableFastRender` would be a workaround for the above.
This commit fixes this by:
* Adding a check for the HTTP request header `Sec-Fetch-Mode = navigation` to the condition for if we should track server request as a user navigation (and not e.g. a HTTP request for a linked CSS stylesheet).
* Making sure that we compare against the real relative URL for non-permalinkable output formats.
Fixes#13014
* Always include the content hash in the cache key for unprocessed images.
* Always include the image config hash in the cache key.
This is also a major cleanup/simplification of the implementation in this area.
Note that this, unfortunately, forces new hashes/filenames for generated images.
Fixes#13273Fixes#13272
The old setup tried to log >= warning to stderr, the rest to stdout.
However, that logic was flawed, so warnings ended up in stdout, which makes `hugo list all` etc. hard to reason about from scripts.
This commit fixes this by making all logging (info, warn, error) log to stderr and let stdout be reserved for program output.
Fixes#13074
