Potential stale result in the Pages slices cache #5239
Comments
bep
added a commit
to bep/hugo
that referenced
this issue
Sep 21, 2018
bep
added a commit
to bep/hugo
that referenced
this issue
Sep 21, 2018
It is slightly slower, but correctnes is, of course, more important: ```bash benchmark old ns/op new ns/op delta BenchmarkSortByWeightAndReverse-4 367 645 +75.75% benchmark old allocs new allocs delta BenchmarkSortByWeightAndReverse-4 2 2 +0.00% benchmark old bytes new bytes delta BenchmarkSortByWeightAndReverse-4 64 64 +0.00% ``` Running the same benchmark without any cache (i.e. resorting the slice on every iteration) and then compare it to the current version shows that it still is plenty worth it: ```bash ▶ benchcmp 2.bench 1.bench benchmark old ns/op new ns/op delta BenchmarkSortByWeightAndReverse-4 1358757 645 -99.95% benchmark old allocs new allocs delta BenchmarkSortByWeightAndReverse-4 17159 2 -99.99% benchmark old bytes new bytes delta BenchmarkSortByWeightAndReverse-4 274573 64 -99.98% ``` Closes gohugoio#5239
bep
added a commit
to bep/hugo
that referenced
this issue
Sep 21, 2018
It is slightly slower, but correctnes is, of course, more important: ```bash benchmark old ns/op new ns/op delta BenchmarkSortByWeightAndReverse-4 367 645 +75.75% benchmark old allocs new allocs delta BenchmarkSortByWeightAndReverse-4 2 2 +0.00% benchmark old bytes new bytes delta BenchmarkSortByWeightAndReverse-4 64 64 +0.00% ``` Running the same benchmark without any cache (i.e. resorting the slice on every iteration) and then compare it to the current version shows that it still is plenty worth it: ```bash ▶ benchcmp 2.bench 1.bench benchmark old ns/op new ns/op delta BenchmarkSortByWeightAndReverse-4 1358757 645 -99.95% benchmark old allocs new allocs delta BenchmarkSortByWeightAndReverse-4 17159 2 -99.99% benchmark old bytes new bytes delta BenchmarkSortByWeightAndReverse-4 274573 64 -99.98% ``` Closes gohugoio#5239
bep
added a commit
to bep/hugo
that referenced
this issue
Sep 21, 2018
This is a slight performance optimization with no functional effect. See gohugoio#5239
bep
added a commit
that referenced
this issue
Sep 21, 2018
It is slightly slower, but correctnes is, of course, more important: ```bash benchmark old ns/op new ns/op delta BenchmarkSortByWeightAndReverse-4 367 645 +75.75% benchmark old allocs new allocs delta BenchmarkSortByWeightAndReverse-4 2 2 +0.00% benchmark old bytes new bytes delta BenchmarkSortByWeightAndReverse-4 64 64 +0.00% ``` Running the same benchmark without any cache (i.e. resorting the slice on every iteration) and then compare it to the current version shows that it still is plenty worth it: ```bash ▶ benchcmp 2.bench 1.bench benchmark old ns/op new ns/op delta BenchmarkSortByWeightAndReverse-4 1358757 645 -99.95% benchmark old allocs new allocs delta BenchmarkSortByWeightAndReverse-4 17159 2 -99.99% benchmark old bytes new bytes delta BenchmarkSortByWeightAndReverse-4 274573 64 -99.98% ``` Closes #5239
bep
added a commit
that referenced
this issue
Sep 21, 2018
This is a slight performance optimization with no functional effect. See #5239
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Debugging a fairly large multilanguage site using
lang.Mergeetc. to pull in content I saw one case of "stale content" from the cache we use to avoid resorting page slices.In the above case, the fix would have been a "cache per site", but I need to look into if the optimization in that cache is perhaps a little too aggressive/unneeded. For larger slices, we currently do not compare every item in the slice, but this obviously can give false positives.
The text was updated successfully, but these errors were encountered: