Add mapDocInPlace to modify the doc without creating unnecessary copies

[f8k8]

This change aims to reduce memory usage, which was reaching over 8GB when processing one .js file (~2k lines, 104KB size) in our project and giving a FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory error. The mapDoc function was creating new objects for everything it processed, and is used to convert end of line characters when the line ending is not lf. Creating new objects for a lot of the doc is unnecessary when the original doc object is not used after the mapDoc call, so this function modifies the original object in place instead of creating new copies.

Note that, because this new function modifies the original, it has only been used where we have identified it is safe to do so. Other places could benefit from it, and we've also added another parameter to escapeTemplateCharacters so that the caller can be explicit as to whether or not to use the new in place version.

• I’ve added tests to confirm my change works.
• (If changing the API or CLI) I’ve documented the changes I’ve made (in the docs/ directory)
• (If the change is user-facing) I’ve added my changes to the CHANGELOG.unreleased.md file following the template.
• I’ve read the contributing guidelines.

[thorn0]

This doesn't look good.

[thorn0]

On the other hand, escapeTemplateCharacters isn't exported and isn't used anywhere else, so a comment should suffice instead of this extra parameter.

[f8k8]

That ternary had an error in anyway that I missed - it used mapDocInPlace for both options. I've pushed a new commit which removes the extra parameter and just adds a comment that the original doc is modified.

[thorn0]

How do you measure the memory usage? I'm on Windows 10 64, testing 1.18.2 on a bundle with 100k lines:

prettier --loglevel debug --debug-repeat 1000 bundle.js > nul

and the memory usage does not even reach 2GB.

[f8k8]

Are the line endings in your bundle.js just lf or are they crlf? If they are lf, then the part that was causing issues will be skipped. We were seeing the issue on a file with crlf line endings. I can send you the specific file which was causing us issues if you want? If you can't reproduce it with your own test, let me know the best way to send it to you.

[thorn0]

I replaced the line endings with crlf and tried running Prettier first with --end-of-line crlf and then with --end-of-line lf, but did not spot any significant difference. Yes, if it's possible, I would test it on your file too to check if there is something special in it that makes Prettier take more memory.

[thorn0]

Reproduced it with your file. 👍

[fisker]

status?

[thorn0]

Fixed by #7891