perf(escapeAllSwigTags): reducing GC overhead

[D-Sketon]

What does it do?

A large amount of string concatenation can result in numerous consString objects, which cannot be cleared during Scavenge. This leads to old generation expansion.

12x many-posts
before PR

after PR

12x many-posts concurrency=20
before PR

after PR

4x many-posts concurrency=20
before PR

after PR

1x many-posts concurrency=20
before PR

after PR

Screenshots

Pull request tasks

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

[github-actions]

How to test

git clone -b perf/mem https://github.com/D-Sketon/hexo.git
cd hexo
npm install
npm test

[coveralls]

Pull Request Test Coverage Report for Build 12972482668

Details

• 22 of 23 (95.65%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 99.492%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
lib/hexo/post.ts	22	23	95.65%

Totals
Change from base Build 12902994421:	0.0%
Covered Lines:	9606
Relevant Lines:	9655

---

💛 - Coveralls

[SukkaW]

I believe that the root cause of the issue is that string concatenation doesn't copy strings; instead, it points to the existing strings using pointers. This is good for performance, so we should retain this behavior.

On the other hand, the concatenated string holds the reference of the old string, preventing the old string from being released.

Instead of manually creating a StringBuilder, you can try replacing return output with return output.replace('#'.repeat(output.length + 1), '') to see if it reduces GC pressure.

See also: https://romgrk.com/posts/optimizing-javascript#8-use-strings-carefully

[D-Sketon]

I tested it briefly and it doesn't seem to make a difference
return output

return output.replace('#'.repeat(output.length + 1), '')

with stringbuilder

I'll follow up with an in-depth investigation.

[D-Sketon]

I might have figured out why there's a memory difference.

Although consString uses references, each consString itself carries a size of 32 bytes.

Assuming each post has 5,000 characters and there are 4,000 posts, consString would occupy an additional 5,000 * 4,000 * 32B = 640MB.

On the other hand, using StringBuilder would result in each post taking an additional 32 bytes (I’m not entirely sure), totaling an additional 4,000 * 32B = 128KB.

[D-Sketon]

@SukkaW Using output.charAt(0) seems to be able to flatten the string in Node20, but it doesn't work on node22.
before

after