Здравствуйте, Юнусов Булат, Вы писали:
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. Выпрямляем своими руками
