Аннотация:
В статье приводятся тесты скорости сериализации и объема сериализованных данных при применении автоматической сериализации в .NET. Обсуждаются варианты исправления ситуации. В качестве примера приводится вариант ручной сериализации для объектов DataSet и DataTable.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewG, Вы писали:
AG>С чем это может быть связано?
Маршалинг... и ничего с этим не сделаешь.... причем это время слабо зависит (вроде) от того, чем пользуешься ( CORBA/COM+/DCOM/.Net Remoting)... у меня та же окрошка... на каждый Remoting вызов с возвратом максимум 100 байт тратится от 50 до 100 милисекунд... добавил в один из Remoting объектов
... << RSDN@Home 1.1 alpha 1 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Re[3]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, AndrewG, Вы писали:
AG>Разнес сериализацию/десереализацию на сервер и клиент. AG>Получил увеличенное время десереализации по сравнению с тестовой программой.
AG>На моих данных в тестовой программе было ~ 2.8 сек, на клиенте получил ~ 4.5
Дык а процессоры то какие на машинах?
AG>С чем это может быть связано?
Нужно сравнить с общем временем передачи по сети. Возможно что-то работало в бэкграунде.
Тут вообще есть смысл сравнить общую скорость передачи данных разными форматерами по сети. Потому, как кроме скорости сериализации будет еще фактор вреемени передачи данных. И он может оказаться куда более весомым.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Владислав Чистяков, Вы писали:
ВЧ>Статья: ВЧ>Сериализация в .NET. Выпрямляем своими руками
Я тоже делал похожие тесты, только, слегка по-другому. Написан собственный бинарный сериалайзер, без особых наворотов типа сериализации MarshalByRef или ISerializable, но графы любой сложности обрабатывает корректно. Так вот после алгоритмической оптимизации (даже без ngen-a) на Framework 1.0 он обгонял стандартный BinaryFormatter в 3-4 раза. После перехода на 1.1 ситуация изменилась, но не кардинально. Ниже результаты в миллисекундах, пишем/читаем один и тот же граф из N-ного числа объектов. С ростом числа объектов отставание стандартного соответственно увеличивается. Про SOAP и XML и говорить не стоит.
Число объектов Собственный CLR STD
~1000 150/160 230/160
~5000 580/851 901/1151
~10000 1412/1632 1912/2734
Размер потоков тоже меньше:
Число объектов Собственный CLR STD
~1000 142053 221380
~5000 715160 1110487
~10000 1436164 2226491
А потом переписали его на Java и ща гоняем объеты в бинарном виде из CLR в JRE без всяких SOAP с XML.
Кого интересует опыт, свистите на knots@tut.by
Re[2]: Сериализация в .NET. Выпрямляем своими руками
Всем привет...
Ребята, нашел эту статью...
Хотелось бы попробовать самому...
Не поделитесь инфой, где можно взять библиотеки архивации (ZLIB и SharpZipLib)...
Может кто-то поделиться...
По ссылке в статье я их не нашел.
Если у кого сохранились, скиньте на мыло alex2808@mail.ru
Или ссылку, где их можно прокачать.
Зеранее благодарен.
Всех благ
Re[3]: Сериализация в .NET. Выпрямляем своими руками
А надо ли гонять по сетке датасет или дататаблу именно в виде хмля?
Это чтобы все могли на данные глядеть чтоли? А оно надо?
Имхо куда сподручнее в виде закомпрессованного (плюс опционально зашифрованного) массива байт гонять — и батлнек ширше и враги ничего не поймуть.
using System.IO;
using System.Data;
using ICSharpCode.SharpZipLib.GZip;
namespace Sior.Data.Compression
{
public class GZipper
{
public static byte[] GetBytes(DataSet ds)
{
if (null != ds)
{
MemoryStream ms = new MemoryStream();
ds.WriteXml(ms);
ms.Seek(0, SeekOrigin.Begin);
return ms.ToArray();
}
return null;
}
public static byte[] CompressBytes(byte[] data)
{
if (null != data)
{
MemoryStream ms = new MemoryStream();
Stream s = new GZipOutputStream(ms);
s.Write(data, 0, data.Length);
s.Flush();
s.Close();
return ms.ToArray();
}
return null;
}
public static byte[] CompressDataSet(DataSet ds)
{
return CompressBytes(GetBytes(ds));
}
public static byte[] DecompressBytes(byte[] data)
{
if (null != data)
{
MemoryStream compressedStream = new MemoryStream(data);
Stream s = new GZipInputStream(compressedStream);
int size = 2048;
byte[] writeData = new byte[size];
MemoryStream decompressedStream = new MemoryStream();
while (true)
{
size = s.Read(writeData, 0, size);
if (size > 0)
{
decompressedStream.Write(writeData, 0, size);
}
else
{
break;
}
}
s.Flush();
s.Close();
decompressedStream.Seek(0, SeekOrigin.Begin);
return decompressedStream.ToArray();
}
return null;
}
public static Sior.Data.DataSetMessages GetDataSetMessages(byte[] data)
{
if (null != data)
{
MemoryStream ms = new MemoryStream(data);
Sior.Data.DataSetMessages ds = new Sior.Data.DataSetMessages();
ms.Seek(0, SeekOrigin.Begin);
ds.ReadXml(ms);
ds.AcceptChanges();
return ds;
}
return null;
}
public static Sior.Data.DataSetMessages DecompressDataSetMessages(byte[] data)
{
return GetDataSetMessages(DecompressBytes(data));
}
Re[5]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Юнусов Булат, Вы писали:
ЮБ>Здравствуйте, alex2808, Вы писали:
A>>А что это за тип данных Sior.Data.DataSetMessages, которые возвращают методы...
ЮБ>Это не из класса, это пример как достать типизованный датасет их компрессованного массива байт.
Sior.Data.DataSetMessages: я понял, что это отдельный класс, наверное обертка для DataSet с функционалом. Где можно увидить его реализацию, это твой класс или из какого-то пакета?
Всех благ
Re[7]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, alex2808, Вы писали:
A>Sior.Data.DataSetMessages: я понял, что это отдельный класс, наверное обертка для DataSet с функционалом. Где можно увидить его реализацию, это твой класс или из какого-то пакета?
Сатый обыкновенный типизованый датасет
Re[2]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Юнусов Булат, Вы писали:
ЮБ>Здравствуйте, Владислав Чистяков, Вы писали:
ЮБ>А надо ли гонять по сетке датасет или дататаблу именно в виде хмля? ЮБ>Это чтобы все могли на данные глядеть чтоли? А оно надо?
Лучше всего гонять именно в таком виде. Сериализация должна знать лишь о типе, но никак не о алгоритмах модификации. Если нужно шифрование или сжатие, то нужно брать подходящее соединение.
Re[3]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Mika Soukhov, Вы писали:
ЮБ>>А надо ли гонять по сетке датасет или дататаблу именно в виде хмля?
MS>Лучше всего гонять именно в таком виде. Сериализация должна знать лишь о типе, но никак не о алгоритмах модификации. Если нужно шифрование или сжатие, то нужно брать подходящее соединение.
Чем лучше ? "Чем грузины"?
Re[3]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Mika Soukhov, Вы писали:
ЮБ>>А надо ли гонять по сетке датасет или дататаблу именно в виде хмля? ЮБ>>Это чтобы все могли на данные глядеть чтоли? А оно надо?
MS>Лучше всего гонять именно в таком виде.
Почему? Голословно.
MS>Сериализация должна знать лишь о типе, но никак не о алгоритмах модификации.
Как будто в моем коде серилизация что то знает. Знаю я, и этого достаточно.
MS>Если нужно шифрование или сжатие, то нужно брать подходящее соединение.
Вариантов куча, выбирай что хошь.
Re[4]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Юнусов Булат, Вы писали:
MS>>Лучше всего гонять именно в таком виде. ЮБ>Почему? Голословно.
Я не пытаюсь тебя убедить. Нет, значит нет
MS>>Сериализация должна знать лишь о типе, но никак не о алгоритмах модификации. ЮБ>Как будто в моем коде серилизация что то знает. Знаю я, и этого достаточно.
Я не совсем про это говорил. Допустим у нас уже есть реализация сжатия и криптования (например, мы используем http + gzip + SSL). Зачем нам писать в своем коде ненужные алгоритмы? Преставим другую ситуацию. Я делаю клонирование объектов через сериализацию. Что, опять криптование и сжатие?
Зашивать в код сериализации такие тяжеловесные алгоритмы не очень разумно. Лучше все разносить по разным уровням.
Re[5]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Mika Soukhov, Вы писали:
MS>Я не совсем про это говорил. Допустим у нас уже есть реализация сжатия и криптования (например, мы используем http + gzip + SSL). Зачем нам писать в своем коде ненужные алгоритмы? Преставим другую ситуацию. Я делаю клонирование объектов через сериализацию. Что, опять криптование и сжатие?
MS>Зашивать в код сериализации такие тяжеловесные алгоритмы не очень разумно. Лучше все разносить по разным уровням.
Еще раз — ну нету у меня реализации сериализации, неужел не видно?
Ради бога найди ее у меня в коде
У меня гоняются не датасеты а массивы байт при чем тут сериализация то?
Re[6]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Юнусов Булат, Вы писали:
ЮБ>Еще раз — ну нету у меня реализации сериализации, неужел не видно? ЮБ>Ради бога найди ее у меня в коде ЮБ>У меня гоняются не датасеты а массивы байт при чем тут сериализация то?
"На нет, и суда нет". Я не читал твой код. Я комментировал твое высказывание. Если у тебя все пучком, только рад
Re[2]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Nivedano, Вы писали:
N>Здравствуйте, Владислав Чистяков, Вы писали:
ВЧ>>Статья: ВЧ>>Сериализация в .NET. Выпрямляем своими руками
N>Я тоже делал похожие тесты, только, слегка по-другому. Написан собственный бинарный сериалайзер, без особых наворотов типа сериализации MarshalByRef или ISerializable, но графы любой сложности обрабатывает корректно. Так вот после алгоритмической оптимизации (даже без ngen-a) на Framework 1.0 он обгонял стандартный BinaryFormatter в 3-4 раза. После перехода на 1.1 ситуация изменилась, но не кардинально. Ниже результаты в миллисекундах, пишем/читаем один и тот же граф из N-ного числа объектов. С ростом числа объектов отставание стандартного соответственно увеличивается. Про SOAP и XML и говорить не стоит.
А что пользует твой форматер рефлекшн или ручками нужно указывать, что сохранять.
Стандартный сериализер толкает тока все доступные свойтсва и выкупает их рефлешином, а он как говорится тормозной. Если делать сериализацю ручками, то оно будет естественно быстрее. В JAVA нет соего автоматического сериализера там все ручками
Есть покопаться на то можно найти кучу велосипедов на эту тему особенно на сайтах по JAVA.
--
То, что вы уникальны еще не значит, что от вас есть толк
Re[2]: Сериализация в .NET. Выпрямляем своими руками
внимательнее. Там четко сказано, что объем данных сериализованных бинарным форматером не намного больше чем ХМЛ-ны. И что основное время уходит именно на сериализацию. Там же дан исходник бинари-форматера и сжатия.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Юнусов Булат, Вы писали:
ЮБ>>А надо ли гонять по сетке датасет или дататаблу именно в виде хмля?
VD>Прочти мою статью
внимательнее. Там четко сказано, что объем данных сериализованных бинарным форматером не намного больше чем ХМЛ-ны. И что основное время уходит именно на сериализацию. Там же дан исходник бинари-форматера и сжатия.
Читал естественно.
Все больше склоняюсь к тому что датасеты это зло
Ну, это ты зря. Сами тадасеты вешь удобная и функциональная. Если применять по месту и с умом, то очень даже...
ЮБ>То все равно хибернатовские клоны типа хро или нхиберната (для моих задач) руль.
Они могут быть еще медленее. К тому же это, как я понимаю, ранние клоны. Да и не конкуренты они с датасетами. С датасетами RFD соревнуется, вроде как успешно.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, VladD2, Вы писали:
VD>Ну, это ты зря. Сами тадасеты вешь удобная и функциональная. Если применять по месту и с умом, то очень даже...
Хочется, чтобы можно было везде и бестолку, ищем панацею панимаишь
ЮБ>>То все равно хибернатовские клоны типа хро или нхиберната (для моих задач) руль.
VD>Они могут быть еще медленее. К тому же это, как я понимаю, ранние клоны. Да и не конкуренты они с датасетами. С датасетами RFD соревнуется, вроде как успешно.
Есть свои недостатки и пряники, приводить не буду на сайты все умеют лазать.
Во всяком случае они базируются на работающем лисапеде. Хро даже пошло дальше простого портирования — отказались от хмль файликов в пользу аттрибутов.
Re[7]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Mika Soukhov, Вы писали:
MS>"На нет, и суда нет". Я не читал твой код. Я комментировал твое высказывание. Если у тебя все пучком, только рад
Вот, по поводу гонений массивов байт а не датасетов, нашел таки. Что те камрады тоже не правы?
Здравствуйте, Mika Soukhov, Вы писали:
MS>"На нет, и суда нет". Я не читал твой код. Я комментировал твое высказывание. Если у тебя все пучком, только рад
Я тож
Re[8]: Сериализация в .NET. Выпрямляем своими руками
На самом деле, вторая статья — это демонстрация возможностей .NET 2.0
Вообще, компресиия — это хорошо. Но не стоит этого делать явно (изви, что я не видел сразу твой код, я думал он такой же, как в статье). Явно — это когда компрессия идет в процессе сериализации. Не нужно этого делать. Мы посылаем данные по Remoting через Binary Formatter. В этом случае DataSet стоит форматировать бинарно и сжимать. А если мы его посылаем через Web Service? Клиент может просто не понять нашего модифицированного потока.
А вообще, статьи так себе. Не сказано самого главного. Да, компрессия снижает сетевой траффик. НО! Она увеличивает нагрузку на сервер. Так что в каждом индивидуальном случае нужен свой подход. Именно поэтому, лучше всего передавать DataSet так, как он передается. Если вдруг пришли какие-то изменения (часть данных для определенных клиентов лучше передевать в сжатом виде), то легче всего встроить дополнительный форматор. Там мы сможет поддерживать абсолютно любой тип клиента (binary, xml, compressed binary, compressed xml).
Re[9]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Mika Soukhov, Вы писали:
MS>На самом деле, вторая статья — это демонстрация возможностей .NET 2.0
Возможно, судя по другой статье тама датасеты и без этого смогут в бинарном виде ходить.
MS>Вообще, компресиия — это хорошо. Но не стоит этого делать явно (изви, что я не видел сразу твой код, я думал он такой же, как в статье). Явно — это когда компрессия идет в процессе сериализации. Не нужно этого делать. Мы посылаем данные по Remoting через Binary Formatter. В этом случае DataSet стоит форматировать бинарно и сжимать.
Догадываюсь iis, http channel, binary formatter, все курили Раммера , интересно во втром фреймворке ремотинг сможет без почесывания левой ногой правого уха через проксю на клиенте ходить?
MS>А если мы его посылаем через Web Service? Клиент может просто не понять нашего модифицированного потока.
Дать клиенту сборку с соап екстеншенcом.
MS>А вообще, статьи так себе. Не сказано самого главного. Да, компрессия снижает сетевой траффик. НО! Она увеличивает нагрузку на сервер. Так что в каждом индивидуальном случае нужен свой подход. Именно поэтому, лучше всего передавать DataSet так, как он передается. Если вдруг пришли какие-то изменения (часть данных для определенных клиентов лучше передевать в сжатом виде), то легче всего встроить дополнительный форматор. Там мы сможет поддерживать абсолютно любой тип клиента (binary, xml, compressed binary, compressed xml).
Подробнее про это самое можно?
Re[10]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Юнусов Булат, Вы писали:
ЮБ>Догадываюсь iis, http channel, binary formatter, все курили Раммера , интересно во втром фреймворке ремотинг сможет без почесывания левой ногой правого уха через проксю на клиенте ходить?
Судя по всем нововведениям, он начинает умирать. Пока что я не видел такой функциональности.
MS>>А если мы его посылаем через Web Service? Клиент может просто не понять нашего модифицированного потока. ЮБ>Дать клиенту сборку с соап екстеншенcом.
Клиенты веб сервиса на то и его клиенты, что они могут быть не .NET.
MS>>А вообще, статьи так себе. Не сказано самого главного. Да, компрессия снижает сетевой траффик. НО! Она увеличивает нагрузку на сервер. Так что в каждом индивидуальном случае нужен свой подход. Именно поэтому, лучше всего передавать DataSet так, как он передается. Если вдруг пришли какие-то изменения (часть данных для определенных клиентов лучше передевать в сжатом виде), то легче всего встроить дополнительный форматор. Там мы сможет поддерживать абсолютно любой тип клиента (binary, xml, compressed binary, compressed xml). ЮБ>Подробнее про это самое можно?
Да взять хотя бы этот сайт. Он может передавать двумя способами, в сжатом и plain-text виде. Если бы он передовался только в сжатом, то некоторые веб клиенты просто бы его не смогли загрузить. В принципе, не сложно сделать и еще одно расширение, которые будет данные не только сжимать, но и передавать сам по себе компактный формат. Например, если написать некое подобие веб сервиса, использующее бинарный формат. Да можно и не только бинарный, а так же формат, который распространен в ini файлах. Намного компактнее xml.
Re[11]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Mika Soukhov, Вы писали:
MS>Судя по всем нововведениям, он начинает умирать.
Король умер ...
в первый раз чтоли
MS>Клиенты веб сервиса на то и его клиенты, что они могут быть не .NET.
Если юзать типизованные датасеты для недотнетовых клиентов то таких клиентов (имхо) проще сразу пристрелить.
Был случай, полученный датасетовый хмль в оракловую хранимку в виде клоба отдавали. Хранимка сама его парсила и по нужным табличкам все записи раскидывала.
Пришлось злобно уговаривать оракал его съесть
Датасетовый хмль пришлось из utf8 переконверчивать в 1251, что не особо благозвучно сказалось на первомансе.
Так же пришлось из датасетового хмлья выбросить его наймспейс (типа строка примерно в виде <DataSetDictionaries xmlns="http://www.tempuri.org/DataSetDictionaries.xsd">) иначе оракал отказывался этот хмль понимать. Снести его как обычную ноду не получалось (оно за каким то хоботом несносимое оказалось) а снести на уровне xsd в студии по неким причинам было нельзя.
А при передаче в обратную сторону та же фигня плюс то что оракал исправно отдавал полную структуру датасета в хмль виде невзирая на то что данных в некоторых столбцах нет отчего датасет этот хмль отказывался вкуривать. Отчего надо было пробегать по нодам и сносить пустые.
Еще что то лезло уже не помню
MS>Да взять хотя бы этот сайт. Он может передавать двумя способами, в сжатом и plain-text виде. Если бы он передовался только в сжатом, то некоторые веб клиенты просто бы его не смогли загрузить. В принципе, не сложно сделать и еще одно расширение, которые будет данные не только сжимать, но и передавать сам по себе компактный формат. Например, если написать некое подобие веб сервиса, использующее бинарный формат. Да можно и не только бинарный, а так же формат, который распространен в ini файлах. Намного компактнее xml.
Все слова знаю, смысл ускользает
Re[5]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, VladD2, Вы писали:
VD>Исхдники были приложены к статьи.
К бумажной статье был CD с исходниками, а на сайте — "покупайте наших слонов!", т.е. никакого кода.
VD>А вообще поробуй пошукать по форуму. Тут ссылки уже не раз проходили.
Page not found по этим ссылкам. Либо — вперед, в инет.
Re[2]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Юнусов Булат, Вы писали:
ЮБ> public static DataSet GetDataSetMessages(byte[] data) ЮБ> { ЮБ> if (null != data) ЮБ> { ЮБ> MemoryStream ms = new MemoryStream(data);
ЮБ> DataSet ds = new Sior.Data.DataSetMessages(); ЮБ> ms.Seek(0, SeekOrigin.Begin); ЮБ> ds.ReadXml(ms); ЮБ> ds.AcceptChanges(); ЮБ> return ds;
ЮБ> } ЮБ> return null; ЮБ> }
Попробовал клас Булата...
Идея классная — DataSet переводит в массив байтов упаковывает его (потрясающе, раз в 100 сжимает), байтовый массив передается влет по сетке...
Но... вот тут то и началось...
Тестирую скорость все на тех же 20 тыс.строк.
Перевод byte[] в DataSet с помощью строки кода
ds.ReadXml(ms);
занимает около 3-х минут...
Операция сохранения из DataSet в byte[]
ds.WriteXml(ms);
всего 8-10 секунд.
Т.е. вся операция выгребки данных и передачи их на клиента с сервака занимает около 4-х минут... !!!!!
Если передавать чистый DataSet без упаковки, то на моем железе — чуть больше минуты...
Может кто-то объяснит парадокс???
З.ы. Я правда немного переделал функции Булата, вместо Sior.Data.DataSetMessages я везде подставил просто DataSet. Все работает... Может в этом и вся соль и это влияет на скорость преобразования?
Как Булат ответил, это у него параметризованный DataSet. Что это такое, и с чем его едят этот параметризованный ДатаСет, может кто подскажет... Где о нем почитать можно? Чем он отличается от обычного?
Всех благ
Re[8]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Andrbig, Вы писали:
VD>>Исхдники были приложены к статьи. A>К бумажной статье был CD с исходниками, а на сайте — "покупайте наших слонов!", т.е. никакого кода.
fixed
Re[9]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrbig, Вы писали:
A>>К бумажной статье был CD с исходниками, а на сайте — "покупайте наших слонов!", т.е. никакого кода.
VD>Видимо код просто потеряли. Пстараюсь исправить эту проблему.
Ok, код появился. Ура!
Но также появился вопрос (по выделенным частям текста):
Byte ZipBase::Compress(System::Byte src[],Level level) __gc[]
{
uLongf len = src->Length+100;
Bytef * dest = new Bytef[len];
Byte __pin *p = &src[0];
int ret = compress2(dest,&len,p,src->Length,level);
p = 0;
switch (ret) {
case Z_MEM_ERROR: throw new System::Exception("There is not enough memory.");
case Z_BUF_ERROR: throw new System::Exception("There is not enough room in the output buffer.");
case Z_STREAM_ERROR: throw new System::Exception("The level parameter is invalid.");case Z_OK: ;
}
Byte buf __gc[] = new Byte __gc[len];
p = &buf[0];
memcpy(p,dest,len);
p = 0;
delete [] dest;return buf;
}
dest выделяется, происходит исключение, dest не освобождается?
Re[10]: Сериализация в .NET. Выпрямляем своими руками
От:
Аноним
Дата:
22.12.04 16:29
Оценка:
Здравствуйте, Andrbig, Вы писали:
A>dest выделяется, происходит исключение, dest не освобождается?
У статьи же название "Выпрямляем своими руками"
Re[10]: Сериализация в .NET. Выпрямляем своими руками
ВЧ>Авторы: ВЧ> Владислав Чистяков
ВЧ>Аннотация: ВЧ>В статье приводятся тесты скорости сериализации и объема сериализованных данных при применении автоматической сериализации в .NET. Обсуждаются варианты исправления ситуации. В качестве примера приводится вариант ручной сериализации для объектов DataSet и DataTable.
Во второй версии фреймворка коновалы из МС не смогли сделать нормальную сериализацию для DataSet при DataSet.RemotingFormat == SerializationFormat.Binary;
Ну не уроды, а ? Проверка корректности датасета, используемая в тесте — падает на датах.
Здравствуйте, Владислав Чистяков, Вы писали:
ВЧ>В статье приводятся тесты скорости сериализации и объема сериализованных данных при применении автоматической сериализации в .NET. Обсуждаются варианты исправления ситуации. В качестве примера приводится вариант ручной сериализации для объектов DataSet и DataTable.
Прочитал статью.
Согласен с автором в том, что иногда в очень редких случаях, когда идет борьба за каждую миллисекунду и за каждый байт, стоит реализовать свою сериализацию под конкретный класс.
Но меня удивили и насторожили результаты тестов. Выигрышь производительности в десятки раз это все таки не слабо.
Поэтому не поленился посмореть код. Оказалось, что структура, которая участвовала в тесте состоит из 4-х полей простых типов (числовые). А сериализация заключается просто в последовательной записи значений полей в поток. И эта функция сериализации годится только для данного класса.
Получается, что автор сравнивает в тестах 3 принципиально отличающихся алгоритма — свою простенькую сериализацию, форматтеры и xml-сериализатор. Но у этих трех алгоритмов принципиально разное предназначение! Я могу понять, когда сравниваются разные алгоритмы сортировки по скорости — в них решается одна задача. Но как можно сравнивать алгоритмы, решающие разные задачи??!! Это все равно, что сравнивать по скорости, например, алгоритм сжатия, алгоритм шифрования DES (симметричный) и алгоритм шифрования RSA (асимметричный). Все три алгорится на входе получают массив байт, на выходе выдают массив байт. И для всех трех можно провести обратную операцию восстановления исходного массива. Но разве корректно было бы их сравнивать по скорости? Да еще сделать свой алгоритм, который шифрует массив байт только определенной структуры и сравнить те три алгоритма со своим. Это же бред!
Еще раз повторюсь. Я не против того, чтобы использовать свою сериализацию для некоторых классов. Но я против того, чтобы сравнивать разные алгоритмы сериализации, так как у них разное предназначение. Ведь такое сравнение фактически вводит людей в заблуждение, так как они начинают думать, что в майкрософте реализовали такие кривые (медленные и генерящие много байтов) алгоритмы сериализации.
CustomSerialization — узкоспециализированный, предназначенный только для конкретного типа данных.
BinaryFormatter — для сериализации произвольных объектов в бинарный вид — не подходит для передачи, например, по веб-сервису, без дополнительного преобразования полученного массива байт в Base64.
SOAPFormatter — для сериализации произвольных объектов в SOAP вид — подходит для передачи по веб-сервису.
XmlSerializer — для сериализации несложных классов в XML — позволяет контролировать (настраивать) внешний вид получаемого XML документа.
Зачем их сравнивать по производительности и размеру получаемого потока?
Что имел ввиду автор, говоря об исправлении ситуации? Какой ситуации?
PS. Извиняюсь, что поднял статью пятилетней давности. Иногда пробивает на почитать какую-нибудь статью с рсдн-а.
Re[2]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Spiceman, Вы писали:
S>Поэтому не поленился посмореть код.
Лучше бы не поленились, и заглянули в код какого-нибудь ObjectWriter/Reader... благо, сейчас это можно. Тогда бы вопросы отпали сами по себе.
S>Получается, что автор сравнивает в тестах 3 принципиально отличающихся алгоритма — свою простенькую сериализацию, форматтеры и xml-сериализатор. Но у этих трех алгоритмов принципиально разное предназначение!
?! Каким образом, бинарный форматтер может извинить _такой_ перерасход по размеру выходного потока. Накладные расходы на "универсальность"? ~40%?! Ага...
И таки в чем "принципиальное" различие алгоритмов? В универсальности форматеров?
S>Что имел ввиду автор, говоря об исправлении ситуации? Какой ситуации?
ЕМНИП, "что сериализация в дотнете сделана очень неоптимально". Что, собственно и было продемонстрированно на примерах. Не верите примерам — полазте по исходным текстам framework'а.
---
С уважением, Сиваков Константин
Re[3]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, gbear, Вы писали:
G>Лучше бы не поленились, и заглянули в код какого-нибудь ObjectWriter/Reader... благо, сейчас это можно. Тогда бы вопросы отпали сами по себе.
А у меня нет никаких вопросов.
S>>Получается, что автор сравнивает в тестах 3 принципиально отличающихся алгоритма — свою простенькую сериализацию, форматтеры и xml-сериализатор. Но у этих трех алгоритмов принципиально разное предназначение!
G>?! Каким образом, бинарный форматтер может извинить _такой_ перерасход по размеру выходного потока. Накладные расходы на "универсальность"? ~40%?! Ага...
Именно универсальность и может оправдать небольшой перерасход ресурсов. Почему думаю не нужно объяснять. А вот почему именно такой перерасход ресурсов — это уже нужно копать. В приведенных тестах бинарная сериализация на 30% (по размеру) хуже ручной. Часть этого объема я могу объяснить тем, что нужно сохранять информацию о типах. В данном случае информацию о типе коллекции и о типах элементов. Причем хранить информацию нужно о типе каждого элемента, так как объявление массива TestData[] ary, еще не означает, что все элементы будут именно типа TestData, а могут быть, например, наследниками этого типа.
В данных тестах на каждый элемент массива приходится примерно от 16 до 34 байтов (посчитано по полям + проверено в отладчике). Плюс 30% — это примерно от 5 до 11 байтов на элемент дополнительной информации, генерируемой бинарным форматтером. Не так уж и много для хранения информации о типе. То есть, накладные расходы получаются большими именно из-за того, что приведенная в тестах тестовая структура содержит очень мало информации — соизмеримо с добавляемой форматтером информацией о типе.
В качестве подтверждения своих слов, увеличил размер структуры, добавив в нее поля. Результат: Custom = 19 041 406 байт, Binary = 20 441 662 байт.
И чем больше будет размер структуры, тем меньше будет разница между Custom и Binary.
G>И таки в чем "принципиальное" различие алгоритмов? В универсальности форматеров?
В частности в универсальности. Внимательнее прочтите мой предыдущий пост, я там кратко изложил различия. Вы ведь не будете спорить о разном назначении форматтеров и XMLSeralizer-а.
S>>Что имел ввиду автор, говоря об исправлении ситуации? Какой ситуации?
G>ЕМНИП, "что сериализация в дотнете сделана очень неоптимально". Что, собственно и было продемонстрированно на примерах.
А по мне так не было оно продемонстрировано.
Re[4]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, Spiceman, Вы писали:
S>Именно универсальность и может оправдать небольшой перерасход ресурсов.
Хренасе "небольшой"...
S>Почему думаю не нужно объяснять.
Нет уж... будте добры
S>Часть этого объема я могу объяснить тем, что нужно сохранять информацию о типах. В данном случае информацию о типе коллекции и о типах элементов. Причем хранить информацию нужно о типе каждого элемента, так как объявление массива TestData[] ary, еще не означает, что все элементы будут именно типа TestData, а могут быть, например, наследниками этого типа.
Ага... Собственно, мысль-то понятна... но, ЕМНИП, в тестах гоняются массивы struct'ов... В связи с чем вопрос... а с каких это пор, мы научились наследоваться от struct?
S>В качестве подтверждения своих слов...
В качетсве подтверждения своих слов, небольшой вопрос... ответ на который ниже по тексту...
Дано:
[Serializable]
public struct A
{
byte a;
}
[Serializable]
public class B
{
byte a;
}
class Program
{
static void Main(string[] args)
{
byte[] a = new byte[1];
byte[] b = new byte[2];
A[] c = new A[1];
A[] d = new A[2];
//Инициируем не null'ами
B[] e = {new B()};
B[] f = {new B(), new B()};
}
}
Догадайтесь, чему будет равна по парная разница (b-a, d-c и f-e) длин потоков, в которые мы данные массивы сериализуем бинарным форматтером.
Так вот... 1, 10 и 15 соотвественно... Попробуете объяснить?
При этом, сериализованный c[0] по длине равен e[0] и на целых 64 байта длиннее чем a[0].
Если же ввести
[Serializable]
public struct C
{
byte a;
byte b;
}
то при сериализации массива таких структур, по сравнению с массивом структур типа A длина потока увеличится всего лишь на 1 байт / на элемент.
Но, при этом, если мы сериализуем c[0] и, гипотетический g[0] типа C — разница будет 5 байт.
Правда круто?
G>>И таки в чем "принципиальное" различие алгоритмов? В универсальности форматеров? S>В частности в универсальности.
Универсальность, знаете ли, бывает и с "человеческим лицом", а не с такой вот гримасой.
G>>ЕМНИП, "что сериализация в дотнете сделана очень неоптимально". Что, собственно и было продемонстрированно на примерах. S>А по мне так не было оно продемонстрировано.
Ну, на вкус и цвет, как говориться...
---
С уважением, Сиваков Константин.
Re[5]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, gbear, Вы писали:
S>>Именно универсальность и может оправдать небольшой перерасход ресурсов. G>Хренасе "небольшой"...
А вы читали что я написал? 7 процентов перерасхода на метаданные — это много? Я же написал, что все зависит от размера сериализуемой структуры. Ручная сериализация имеет смысл, когда размер метаданных соизмерим с объемом самих данных.
PS. Хочется все таки вести более конструктивный диалог. Для этого я разделил этот диалог на несколько нитей.
Re[5]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, gbear, Вы писали:
S>>Почему думаю не нужно объяснять. G>Нет уж... будте добры
Дополнительные ресурсы требуются для сохранения метаданных о сериализуемом типе. Эта информация будет использована для десериализации.
В ручной сериализации сохранять метаданные смысла нет, так как эта информация о типе задается в самом алгоритме сериализации.
G>Догадайтесь, чему будет равна по парная разница (b-a, d-c и f-e) длин потоков, в которые мы данные массивы сериализуем бинарным форматтером. G>Так вот... 1, 10 и 15 соотвественно... Попробуете объяснить?
Да что тут объяснять. Разный объем требуется для сохранения разных метаданных. Почему именно такие числа — значит именно столько требуется, чтобы в метаданных сохранить информацию о том, что элементы первого массива — байты, воторого — структура A, а третьего — класс B. Причем я не уверен, но вполне возможно, что для классов требуется сохранять несколько больше информации. Но в любой случае именно столько ее и требуется для того, чтобы можно было потом восстановить.
Разбираться с тем, почему получается именно столько байт честно не хочется. Но уверен, что специалисты майкрософта многое предусмотрели и раз байтов получается именно столько, значит столько и нужно. По крайней мере ни в статье, ни в этой ветке на форуме я не нашел опровержения.
G>Правда круто?
Круто Ага
Re[5]: Сериализация в .NET. Выпрямляем своими руками
Здравствуйте, gbear, Вы писали:
G>>>И таки в чем "принципиальное" различие алгоритмов? В универсальности форматеров? S>>В частности в универсальности. G>Универсальность, знаете ли, бывает и с "человеческим лицом", а не с такой вот гримасой.
Опять же не нашел ни в статье ни в этой ветке, в чем же заключается эта гримаса.
Но дело ведь не только в универсальности. Вы не читали мое сообщение. Дело в том, что ручная сериализация, форматтеры и XMLSerializer не являются взаимозаменямыми и используются для различных целей. Вы же не используется алгоритм шифрования, когда вам нужно сжатие.
Я вообще никак не могу понять, в чем вы со мной не согласны. Я так понимаю, что у вас основная мысль в том, что бинарный форматтер реализован не оптимально. Не буду с этим спорить. Может и не оптимально. Может быть его можно было реализовать производительней. Изучение тонких мест алгоритма BinaryFormatter-а — это целая отдельная тема для статьи.
Моя же основная критика этой статьи заключается в том, что сравнивать производительность можно только у взаимозаменяемых алгоритмов. Например, можно сравнить два различных алгоритма сортировки массивов, а потом придумать свой алгоритм более производительный и запатентовать его. Но сравнивать между собой алгоритмы, предназначенные для разных целей (не взаимозаменяемые) нельзя. Никому ведь в голову не придет использовать форматтеры для того, чтобы создать XML документ. А если и придет, то ничего у него не получится.
Надеюсь моя мысль понятна?
