foghegehog / compactserializer

A compact way to serialize plain .Net objects using Reflection.Emit.

CompactSerializer

This repository contains compact and quick approach for serializing plain .Net objects that have to be stored in a cache. The main idea is to enumerate the same list of object properties during write and read, and save/restore their byte representations in the exactly identical sequence, one after another, without any metadata.
Though, according to MSDN, Type.GetProperties() method does not guaranty returning properties in the declaration or alphabetical order, the sequence returned for the same version of the same type obviously stays identical from call to call. Thus, even re-created serializer should correctly restore previously serialized object. Sure, when the set of object properties is modified, this approach will not work, but as as indicated above, the intended use is to store data in cache. The serialization process includes saving type version, and the easiest way to handle object's source code modification is just invalidate corresponding key in the cache upon the system's update. (That doesn't mean that other ways aren't possible.)

Reflection is not considered a fast mechanism, and calling Type.GetProperties() for each serialization and deserialization operation may not be very productive. The more effective approach is to take the properties list once and generate a code with corresponding sequence of instructions. The Reflection.Emit namespace and ILGenerator class offers suitable code generation capabilities.
The compilation of emitted code can take a while, but if the system runs for a long time, that delay will be fully compensated by the performance increase of following saving/restoring operations.

For the initial implementation, only simple property types are supported, without classes, structures, circular references etc, but including simple containers and Nullable. The exact list of supported types is::

1. byte
2. bool
3. int, short, long
4. uint, ushort, ulong
5. double, float, decimal
6. Guid
7. DateTime
8. DateTimeOffset
9. char
10. string
11. Array<T> (T[]), where T - one of the types listed above;
12. Containers, implementing ICollection and having parameterless constructor. (T should be one of the types listed in points 1-10);
13. Nullable<T>, where T is one of the types listed in points 1-10;

For some of them getting bytes representation is trivial, such as calling Guid.ToByteArray() or BitConverter.GetBytes(value), for other more complex logic had to be applied.

This implementation was compared to System.Runtime.Serialization.Formatters.Binary.BinaryFormatter and Newtonsoft JsonSerializer on performance speed and representation bytes count. When run with object of the kind it was designed for, even pure Reflection version performed faster, than these two serializers. In compactness, surely, both Reflection and Reflection.Emit realizations were superior to library analogs.
The exact experiment results were like this:

Serializer	Average elapsed, ms	Size, bytes
EmitSerializer	10.9168	477
ReflectionSerializer	23.5812	477
BinaryFormatter	239.1568	1959
Newtonsoft JsonSerializer	68.4361	1157

EmitSerializer compiled in: 105.1458 ms

compactserializer's Issues

Зачем полностью генерировать столько кода

Все проще - прочитали значение свойства на вершину стека, позвали соответствующий метод System.IO.BinaryWriter
Для тех типов которые не поддерживаются BinaryWriter напрямую делаем хелпер:

public static class BinaryWriterHelper{
   public static void WriteDateTime(BinaryWriter writer,  DateTime value){
     // Нафига эмитить для каждого свойства код если его можно в статический метод написать руками а потом просто эмитить вызов статического метода? 
   }
}

Сжатие LZ4 как компромисс между скоростью и размером

Посмотрите сюда:
https://github.com/MiloszKrajewski/lz4net

Естественно надо оценить затраты на распаковку в Вашем случае, стоит ли игра свеч