> пожалуйста подробнее про оверхед в текстовых протоколах, а то я видимо > что-то пропустил > Бинарный протокол должен быть экономнее по памяти, например число будет одним > байтом представлено вместо числа байт равному числу цифр, имена полей будут > кодами вместо человекопонятных наименований. а вот это всеобщее заблуждение. КАК ПРАВИЛО в бинарных протоколах числа представляются в фиксированной длине. при этом КАК ПРАВИЛО люди оперируют числами близкими к нулю мы сравнивали оверхед по базе данных, хранящих 10 млн юзеров с настройками, так вот текстовая форма была банально компактнее из за того что в blob средняя чиселка занимала 4-8 байт, а в тексте 1-3. > А если протокол ещё и с фиксированным размером полей (чего в текстовых > протоколах обычно не делают), то в тексте отсутствующие поля не передаем, а в blob они присутствуют из за того что структуры фиксированные и blob'ы как раз и ваяют там где лень о расширениях думать. и тут опять текст в большинстве случаев выигрывает в размерах > то и парсинг его будет быстрее не нужно ходить по > байтам и смотреть не конец ли это строки что blob парсить что текст - парсить в любом случае надо. что blob что текст парсится в общем случае простым однопроходным парсером, написанном например на ragel/flex со скоростью парсинга соизмеримым с memcpy. > - сразу режем кусок нужного размера. тут Вы витаете в каких-то облаках. в случае СЕТЕВОГО протокола все немного не так. вернее все совсем не так. резать кусок нужного размера можно только в одном случае - если на другом конце строго ваш же код - во первых и никаких проблем в сети нет - во вторых -- . ''`. Dmitry E. Oboukhov : :’ : email: unera@debian.org jabber://UNera@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Attachment:
signature.asc
Description: Digital signature