Bugzilla

This is for `innerHTML`/`DOMParser` and not for parse from the network, right? And specifically for `nsHtml5Tokenizer::strBuf`, right?

For `innerHTML`/`DOMParser` it would be feasible to reuse that memory. The risk is that `strBuf` stretches to the worst case of the parser invocation, so if we unconditionally reuse the memory, a parse that needs an exceptionally long buffer would cause a memory leak-like situation with the long buffer sticking around for the rest of the process lifetime.

So we'd probably need some mechanism to delete an overlong buffer anyway. If we just put a magic threshold in `nsHtml5Tokenizer::end`, the delete would still show up on profiles if benchmark caused allocation above the threshold in a loop.

The fancy way would probably be to have an idle task delete the buffer if it's longer than constant.

This is for `innerHTML`/`DOMParser` and not for parse from the network, right? And specifically for `nsHtml5Tokenizer::strBuf`, right?

For `innerHTML`/`DOMParser` it would be feasible to reuse that memory. The risk is that `strBuf` stretches to the worst case of the parser invocation, so if we unconditionally reuse the memory, a parse that needs an exceptionally long buffer would cause a memory leak-like situation with the long buffer sticking around for the rest of the process lifetime.

So we'd probably need some mechanism to delete an overlong buffer anyway. If we just put a magic threshold in `nsHtml5Tokenizer::end`, the delete would still show up on profiles if benchmark caused allocation above the threshold in a loop.

The fancy way would probably be to have an idle task delete the buffer if it's longer than some magic constant.