The class SObjectList function WriteXml(XmlWriter writer) creates a new XmlSerlializer inside a loop, which is very inefficient. Putting the serializer creation outside of the loop increases speed and decreases memory usage.
Each new XmlSerlializer is internally compiled and cached, so for long running applications* the memory usage will slowly rise over time as the cached serializers can never be garbage collected. To reuse a cached serializer you must use a constructor XmlSerializer(typeof(T)) but that means you will need to use an [XmlRoot("sObject")] attribute on your models (?). Or use your own caching strategy, see this link for details:
* We use Azure Functions to send bulk data to Salesforce on a schedule, which would slowly climb to >3GB private bytes used before crashing. Since making this change the private bytes used have flat-lined at ~200MB
The class
SObjectList
functionWriteXml(XmlWriter writer)
creates a newXmlSerlializer
inside a loop, which is very inefficient. Putting the serializer creation outside of the loop increases speed and decreases memory usage.Each new
XmlSerlializer
is internally compiled and cached, so for long running applications* the memory usage will slowly rise over time as the cached serializers can never be garbage collected. To reuse a cached serializer you must use a constructorXmlSerializer(typeof(T))
but that means you will need to use an[XmlRoot("sObject")]
attribute on your models (?). Or use your own caching strategy, see this link for details:https://stackoverflow.com/questions/23897145/memory-leak-using-streamreader-and-xmlserializer
* We use Azure Functions to send bulk data to Salesforce on a schedule, which would slowly climb to >3GB private bytes used before crashing. Since making this change the private bytes used have flat-lined at ~200MB