protobuf-net вопрос о производительности сериализации

Я начал тестировать protobuf-net на предмет сериализации. Я видел тесты (http://www.servicestack.net/benchmarks/NorthwindDatabaseRowsSerialization.100000-times.2010-08-17.html), который предлагал более быструю сериализацию и меньшие файлы.

Я действительно вижу огромную разницу в размере создаваемых файлов. Однако скорость, которую я вижу, находится в пределах 5% от DataContractSerializer WCF.

Это заставило меня задуматься, не делаю ли я что-то не так?

Вот код моих тестов:

private static void ProtoBufSerializer(IQueryable<DataRow> details)
    {
        List<DataRow> list = details.ToList();

        using (var file = File.Create("protobuf2.bin"))
        {                
            Serializer.Serialize<List<DataRow>>(file, list);
        }
    }

    private static void DataContractSerializer(IQueryable<DataRow> details)
    {
        DataContractSerializer serializer = new DataContractSerializer(typeof(List<DataRow>));
        List<DataRow> list = details.ToList();

        using (FileStream fileStream = new FileStream("testSerializationDataContract.xml", FileMode.Create))
        {
            serializer.WriteObject(fileStream, list);
        }            
    }

[ProtoContract]
public class DataRow
{
    [ProtoMember(1)]
    public DRFDataRow DrfDataRow;

    [ProtoMember(2)]
    public Guid guid;
}

[ProtoContract]
public class DRFDataRow : FixedWidthRow
{
    [ProtoMember(1)]
    public int CompanyNumber { get; set; }

    // several fields abreviated for brevety
}

[ProtoContract, ProtoInclude(100, "DRFDataRow")]
public abstract class FixedWidthRow : IProviderRow
{
    // several fields abreviated for brevety

В моем списке около 73 тыс. Пунктов. Каждый элемент невелик, хотя в DRFDataRow много полей (около 50).

P.S .: Я не жалуюсь, я очень доволен результатами, поскольку размер сериализованных результатов намного меньше, мне просто интересно, могу ли я также воспроизвести прирост скорости, который я видел на тестах.


.net protobuf-net
person Gilles    schedule 19.04.2011    source источник

Ответы (1)


arrow_upward
1
arrow_downward

В этом примере не совсем понятно, где отсчет времени начинается и заканчивается - например, если вы включаете время для выборки данных из IQueryable[<T>], то это, скорее всего, будет узким местом. Контракты выглядят нормально; при желании возможны небольшие оптимизации, но ничего серьезного (хотя использование подобъектов на основе групп должно немного помочь, избегая некоторой буферизации; добавьте DataFormat=DataFormat.Group к подобъектам [ProtoMember(... {here})] и [ProtoInclude(... {here})]).

Если проблема не в IQueryable[<T>], то, возможно, стоит попробовать v2 (в настоящее время доступна как альфа-версия или как исходный код), которая полностью изменяет внутреннее устройство.

Для более подробного ответа мне понадобится полностью воспроизводимый пример для исследования.

person Marc Gravell    schedule 19.04.2011
comment
Вы правы, узким местом, конечно же, является получение данных, которые учитываются почти все время. Отсчет времени начинается до вызова метода. Я изменил метод, чтобы взять уже выбранный список и рассчитать только сериализацию, и результаты отличные. 2,02 секунды для сериализации с помощью DataContractSerializer и 0,83 секунды для сериализации с помощью protobuf-net. Я действительно не думаю, что мне нужно будет оптимизировать эти результаты даже при использовании фактических данных (это было по сравнению с тестовыми данными, которые меньше). - person Gilles; 19.04.2011