Some of our beta testers have said that they are not happy with the longer wait times they now encounter when saving their projects using one of our new JUCE-based plugins. While the new plugins do have more parameters than the pre-JUCE ones, it is the use of XML that seems to be the issue here. Our old software streamed binary parameter values directly to the provided buffer, which is apparently much faster than the createXml() function used to save the data from our value tree state. Also involved to some extent is the fact that the tree must be copied before createXml() is called on the copy (to avoid changes while writing, I assume).
Now, as a developer and maintainer of software, I love the flexibility and ease of providing backwards-compatibility that XML provides as compared to pure binary data. But I’m wondering if anyone else has seen this kind of slowdown in saving their session state, and if there were any optimizations that eased the problem?
By the way, these users who have complained have in excess of 50 tracks, each with a copy of our plug-in on it, which is why any minor slowdown becomes an issue, taking 5-10 seconds at times to save their sessions. They have stated that they like to save all the time, and this kind of delay is extremely annoying.
Any thoughts/ideas? I’d hate to lose the XML flexibility and revert to our old methods of saving and loading data, but it may need to happen if there isn’t a way we can get better performance out of the XML method of saving data.