Это хорошая идея для кэширования экземпляров DataContractSerializer?

Question

Я пишу приложение службы Windows, которому необходимо многократно сериализовать и десериализовать XML-документы во время его выполнения. Поскольку мне нужно сериализовать и десериализовать универсальные типы, которые не известны во время компиляции (я априори не знаю, сколько типов мне нужно сериализовать / десериализовать), я хотел бы знать, если это хорошая идея, сохранить кеш объектов DataContractSerializer, которые я создаю для сериализации и десериализации объектов.

Я задаю этот вопрос, потому что я знаю, что это хорошая идея для кэширования экземпляров класса XmlSerializer, поскольку они создают динамическую сборку в памяти под капотом, а сборки, динамически создаваемые в памяти, не собираются мусором.

Я читал, что DataContractSerializer опирается на облегченную генерацию кода, но я не обычно с деталями этого. Вот почему я задаю этот вопрос, мне нужно понять, если я создаю экземпляры DataContractSerializer по мере необходимости, это приведет меня к утечке памяти, как это делает XmlSerializer?

Я решил использовать DataContractSerializer вместо XmlSerializer для возможности сериализации внутренних свойств.

Answer 1

... рекомендуется кэшировать экземпляры класса XmlSerializer, поскольку они создают динамическую сборку в памяти под капотом ...

С XmlSerializer это на самом деле зависит от того, используете ли вы простой конструктор (new XmlSerializer(typeToHandle)) или более сложные конструкторы, которые позволяют вам задавать все атрибуты и т. Д. Во время выполнения. Если вы используете только простой конструктор, он повторно использует фоновую сборку, поэтому штраф за повторение не взимается.

Я бы ожидал, что (но не проверял) DataContractSerializer будет работать аналогично; но, конечно, нет ничего плохого в простом кэшировании, возможно, в статическом поле только для чтения

Обратите внимание, что DataContractSerializer ограничивает доступный вам макет xml ... при условии, что вы согласны с этим; -p