C#: Сериализация объектов в XML без отражения

Question

В приложении мы можем сохранить текущее состояние приложения и его конфигурацию (которая может быть огромной). Мы используем XmlSerializer.

Теперь у нас есть только то, что нам нужно в XML (все XmlIgnore на месте), и очень медленно хранить всю конфигурацию (файл ~ 50-100 МБ).

Мы должны держать хранения такой конфигурации, как XML, но мы хотели бы избежать:

• Отражение, которое замедлять
• реализовать интерфейс IXmlSerializable

Идея должен был иметь метод для реализации в каждом объекте, в котором мы можем зарегистрировать, какие поля/свойство мы хотим сериализовать, а затем иметь SerializationManager, который может читать то, что мы хотим сериализовать, а затем написать их.

Таким образом, объекты не знают язык (XML), в котором они будут визуализированы, и если однажды нам понадобится двоичная сериализация (или если мы хотим иметь возможность сериализации в другом формате), мы Можно.

Но мы не хотим изобретать велосипед, и я не знаю, если какая-то библиотека существует, или если что-то вроде Linq для XML может помочь, или, если это возможно изначально ...

Так как вы думаете, я могу это достичь?

Answer 1

«Отражение, которое замедляться»

За исключением, он не использует отражение во время выполнения. Он выполняет метапрограммирование при первом запуске (при условии, что вы используете new XmlSerializer(type)) для проверки типа и генерации статического кода , который будет работать с данным типом. Поэтому любая проблема производительности, связанная с объемом, не связана с отражением. Там есть шанса, что метапрограммирование сам может занять ощутимое время, но: это маловероятно, если ваша модель не действительно сложна, и б: его можно избежать с помощью инструмента sgen.exe предварительно генерировать сериализация.

Любая проблема с производительностью, поэтому, скорее всего, из-за размера модели и накладных расходов xml.

Если вы хотите попробовать другой сериализатор, рассмотрите что-то вроде protobuf-net. Вы не сможете прочитать данные (это не будет xml), но выход будет намного меньше и быстрее.

Answer 2

Как вы упомянули

В приложении мы можем сохранить текущее состояние приложения, и это конфигурация

государственный, особенно если он большой (100Mb является ... огромным!), потребовал собственный способ сериализации данных. Многие из нас знают и ненавидят, что медленная экономия/загрузка игры спасает от прошлого. Даже сейчас разработчики игр различают quicksave от порядковых сэйвов.Он оптимизирован для выполнения быстрее (например, путем кэширования части недавно выполненного quicksave), чем ординальное сохранение.

Первый вопрос - почему XML? BinarySerializer быстрее, но для таких размеров вам лучше использовать ручную сериализацию (как предложил Марк Гравелл, использовать protobuf, он превосходит все).

Второй вопрос: вам действительно нужно serialize данные (изменить их формат)? Самый быстрый способ сохранения состояния - сброс памяти. Представьте, что все ваши данные сохранены в одном блоке памяти, а затем сброс этого блока в файл - очень быстрое сохранение. Вы можете (я не уверен, но это должно быть выполнимо) построить ваши данные таким образом, что переопределение этой памяти будет loading. Это намного быстрее любого преобразования.

Если вы идете с демпинга, тогда подумайте о его упаковке (в почтовый индекс). Упаковка и сохранение 10 мб должны быть быстрее, чем сохранение распакованных 100 мб (при условии, что вы не используете слишком медленный или слишком хороший алгоритм упаковки), операции с памятью и процессор намного быстрее, чем SSD.

Чтобы сохранить конфигурацию, вы все равно можете сериализовать ее, как обычно. Если вы хотите быть один файл, а затем определить собственный формат этого файла, к примеру:

config_stream, separator["<<<>>>>"], memory block [100 Mb] 

Serialize с XmlSerializer в память, создать файл, сохранить конфигурации, разделитель, дамп.