perf: reduce the number of traversals through posts

[stevenjoezhang]

What does it do?

Calling post.tags[0].length is slow, because Hexo will try to fetch all posts associated with one tag, which is unnecessary.
Tested with 8000 posts (copy https://github.com/SukkaLab/hexo-many-posts 16 times, with https://github.com/hexojs/hexo-starter), this patch will reduce the time of hexo g from ~17min to ~11min

TODO: PostTag.find is also slow. Need to replace it with a better data structure in the future.
See #2579 (comment)
See also #3624

Screenshots

Pull request tasks

• Add test cases for the changes.
• Passed the CI test.

[github-actions]

Publish flamegraph to https://efdf0a4dbdcaa37c86860b8371719f7adcd6e1f8-16-hexo.surge.sh/flamegraph.html

[coveralls]

Coverage increased (+0.002%) to 98.673% when pulling 5f42a03 on perf into ca51e15 on master.

[stevenjoezhang]

Although this patch can mitigate performance issues, Hexo still spends a lot of time dealing with post tags when the site has a lot of posts.

As shown in the figure below, nearly half of the processing time is related to the tags.

It's difficult to make further optimizations for this issue with the current warehouse implementation. Perhaps we could consider supporting other database backends such as sqlite.

[SukkaW]

Although this patch can mitigate performance issues, Hexo still spends a lot of time dealing with post tags when the site has a lot of posts.

As shown in the figure below, nearly half of the processing time is related to the tags.

It's difficult to make further optimizations for this issue with the current warehouse implementation. Perhaps we could consider supporting other database backends such as sqlite.

IMHO warehouse is still our best possible solution.

warehouse put all the data in the memory, which makes it faster for smaller websites (which most Hexo-powered sites are), while it might not scale well with larger sites.