domToText: Performance issue in large projects

I’m investigating performance issues when working with large blocks programs (in MakeCode Arcade), and Blockly’s domToText method came up as a hot path due to a regexp replace it executes. This regexp was added in https://github.com/google/blockly/pull/2663 (Textarea Field, Multiline Block (from acbart)). Here’s the line in question: https://github.com/google/blockly/blob/ba68081d8f0f8e81d76baf370716d5955bae82a1/core/xml.js#L319

This regexp runs repeatedly on the document, causing domToText to take a significant amount of time when the xml is very large. Without this regexp, saving takes practically no time at all.

If you could help me understand the purpose of this search/replace, perhaps I could come up with another approach. And if you have a suggestion for how to improve or remove it, I would be happy to try it and report back.

OS: Windows 10 Browser: Chrome 83

[eanders-ms]

@BeksOmega thank you that info is super helpful! I made a fix in MakeCode’s fork: https://github.com/microsoft/pxt-blockly/pull/315, and will open one here too.

[BeksOmega]

Hi! I’m not actually on the Blockly team, but I do know some stuff about this area, and I think I have some ideas =)

So it looks like this was added by the same change that added the multiline input field. It looks like it’s going through and replacing all \n (linebreak) characters with the escaped versions so that the field correctly round-trips through XML.

Example escaped xml:

<xml xmlns="https://developers.google.com/blockly/xml">
  <block type="test_fields_multilinetext" id="jGDBz^O9+Zz6-r@84/|u" x="13" y="13">
    <field name="CODE">default1&#10;default2</field> <!-- See &#10; escaping -->
  </block>
</xml>

So it is necessary for the multiline text field, but I don’t think it’s necessary to run the search-and-replace over /all/ of the XML.

If you want to take a crack at fixing this I would move the search-and-replace into a toXml function that lives on the multiline text field. That should (hopefully) save time in serialization because the search-and-replace will only run when it absolutely has to.

Thank you so much for looking into this that’s really cool!