Оптимизация сериализации в .NET
ОГЛАВЛЕНИЕ
Введение
Это первая из двух статей про оптимизацию сериализации, особенно для использования в удаленном взаимодействии.
Эта первая статья содержит универсальный код, который используется для сохранения 'принадлежащих данных' (определяются позже) в компактную структурную единицу с максимальной скоростью. Вторая статья приводит пример того, как использовать этот код для сериализации наборов данных как автономных блоков. Возможная третья статья расскажет, как сериализовать Entity и EntityCollections из LLBLGenPro - ведущей O/R программы управления памятью – как пример того, как использовать весь процесс сериализации для получения наилучших результатов. Хотя это написано для одного конкретного приложения, вы можете найти эти методы полезными и для своего кода.
Если вы использовали удаленное взаимодействие .NET для больших объемов данных, то наверняка обнаружили, что в нем есть проблемы с расширяемостью. Для небольших объемов данных оно работает достаточно хорошо, но большие объемы отнимают много ресурсов процессора и памяти, генерируют огромные объемы данных для передачи и могут привести к сбою из-за нехватки памяти. Также большой проблемой является время, требуемое для реального выполнения сериализации – большие объемы данных может быть нереально использовать в приложениях, независимо от затрат ресурсов процессора/памяти, просто потому что выполнение сериализации/десериализации отнимает очень много времени. Использование сжатия данных через приемники сервера и клиента может помочь уменьшить итоговый размер передаваемых данных, но не позволит устранить излишние объемы данных на более ранних этапах процесса.
Вы не можете винить в этом .NET, учитывая всю работу, которую она делает: она обеспечивает выявление целого графа объектов, требуемых для воссоздания исходного объекта, и многократные ссылки на один и тот же объект обрабатываются должным образом, чтобы обеспечить то, что только один общий экземпляр десериализуется. Она также вынуждена делать это через отражение, и иметь возможность делать это без каких-либо априорных знаний о включенных объектах, так что в целом она выполняет довольно хорошую работу. Она также дает вам возможность принять участие в процессе сериализации/десериализации, позволяя вам реализовать интерфейс ISerializable, если вы знаете, как сделать что-то лучшее, чем просто восстановление эксплуатационных данных через отражение.
'Априорное знание' – это ключевой момент здесь. Его можно использовать для оптимизации сохранения определенных 'принадлежащих данных' (определяются позже), оставив всю остальную работу .NET. Это и есть предмет данной статьи.
Позвольте привести пример возможного масштаба оптимизации:
Имеется набор справочных данных из 34,423 строк в таблице базы данных, который был сохранен в виде коллекции объектов-сущностей. Ее сериализация (с помощью MemoryStream для максимальной скорости) занимает целые 92 секунды, и на выходе получается 13.5Мб сериализованных данных. Их десериализация отнимает примерно 58 секунд – не очень удобно для сценария удаленного взаимодействия!
Используя методы, описанные в данной статье, можно при сериализации тех же самых данных получить на выходе 2.1Мб, что отнимет всего 0.35 секунд на сериализацию и 0.82 секунды на десериализацию! Доля использования ресурсов процессора и памяти будет небольшой частью от тех, которые использует исходный сериализатор .NET.
Использование кода
Как указано во введении, загружаемый код достаточно универсален, поэтому в нем, по сути, не содержится ничего специфического для удаленного взаимодействия. По существу, вы помещаете 'принадлежащие' данные в экземпляр класса SerializationWriter и затем используете метод ToArray, чтобы получить byte[],SerializationInfo,ISerializable.GetObjectData(), как обычно, таким образом: содержащий сериализованные данные. Затем его можно сохранить в параметре передаваемом методу
public virtual void GetObjectData(SerializationInfo info,
StreamingContext context)
{
SerializationWriter writer = new SerializationWriter();
writer.Write(myInt32Field);
writer.Write(myDateTimeField);
writer.Write(myStringField);
// и т.д.
info.AddValue("data", writer.ToArray());
}
Десериализация, по существу, обратный процесс: в конструкторе десериализации вы извлекаете byte[] и создаете экземпляр SerializationReader, передавая byte[] его конструктору. Затем данные извлекаются в том самом же порядке, как они были записаны:
protected EntityBase2(SerializationInfo info, StreamingContext context)
{
SerializationReader reader =
new SerializationReader((byte[]) info.GetValue("data",
typeof(byte[])));
myInt32Field = reader.ReadInt32();
myDateTimeField = reader.ReadDateTime();
myString = reader.ReadString();
// и т.д.
}
Просто скопируйте файл FastSerializer.cs в ваш проект, измените пространство имен соответственно, и он будет готов к использованию. Прикрепленные к статье файлы также включают в себя файл FastSerializerTest.cs с более чем 220 тестами, но в этом нет особой необходимости, и вам стоит его добавить только в том случае, если вы хотите изменить код с гарантией того, что ничего не будет испорчено.