Здравствуйте, netch80, Вы писали:
N>ASN.1 был пионерской разработкой. Крайне сложный язык описания структур, неэффективные кодировки в двоичку, и всё такое.
Он крайне сложный только для тех кто не знаком с матчастью теории компиляторов. Понятно, что АСН.1 был создан под задачи того времени и людьми которые были в наличии, а это были не самые плохие спецы . Кроме BER есть PER где упаковка идёт на битовом уровне, поэтому там была нужна эффективность, её можно было использовать.
N>Это подвиг, но много моментов решено неоптимально.
Например?
N>Если говорить о чём-то современном близкого типа, то это CBOR. У него плотность представления в двоичке выше раза в два, чем у BER. Текстовое представление почти полностью соответствует JSONʼу, то есть понятно всем по современным подходам.
Возможно, будущий кандидат для замены json. Хотя у нас всегда был бинарный xml как бы сам xml ненавидели.
N>Но всё же, как сказал ТС, люди занимаются фигнёй вместо главного...
А чем они должны заниматься? Мне вот кажется мы скоро начнём входить на новый виток оптимизации бесконечных джейсонов и текста чтобы не грузить сервера лишним трафиком и разбором. Сразу все вспомнят как деды проектировали системы, про бинарные протоколы, про CORBA, и про другие технологии переосмыслив их в текущих реалиях лишь бы уменьшить нагрузку на железо, трафик и управление системами. Это же надо, люди когда-то боролись с оверхедом IP заголовков придумав ROHC но всё про##&*@ тупо добавив текст во всех протоколах выше транспорта.
Here’s an article on GigaOm from 2012 titled "The Growing Epidemic of Page Bloat". It warns that the average web page is over a megabyte in size.
The article itself is 1.8 megabytes long.
Here's an almost identical article from the same website two years later, called “The Overweight Web". This article warns that average page size is approaching 2 megabytes.
That article is 3 megabytes long.
If present trends continue, there is the real chance that articles warning about page bloat could exceed 5 megabytes in size by 2020.
И ведь угадал.
На самом деле, в этом бы не было проблемы, если бы за этим стоял прогресс. Если бы читать становилось удобнее. Как-то. (Но как можно сделать чтение статей более удобным? Это то, про что автор говорит: “This talk isn't about any of those [big websites packed with images <…> or well-designed web apps]. It's about mostly-text sites”). Но эти ресурсы же идут на гидратацию, например. Которая, как бы, экономит ресурсы. Но в реальности ресурсы не экономятся, а что касается удобства, я бы вырвал рученьки тому, кто её придумал. Потом, ресурсы идут на аналитику. Ну, тут uBlock Origin нам в помощь? Потом ресурсы идут на хрен пойми что. Но я не до конца дочитал.
P.S. И про Medium в точку. Вот его я как раз вспоминал много раз в связи с этим всем. Я даже так рискну обобщить: они все идут по дорожке «браузер в браузере». Своя загрузка, своя обработка всего и вся. Опять же, он там намекает, что медиумы сознательно это делают, в общем, пошёл я дочитывать.
Здравствуйте, Hobbes, Вы писали:
N>>Если говорить о чём-то современном близкого типа, то это CBOR. У него плотность представления в двоичке выше раза в два, чем у BER. H>Так есть же PER.
Теперь сравниваем PER, который сложен даже просто чтобы понять описание (я когда-то понял — но всё забыл и мне теперь придётся, если потребуется, перечитывать его заново), и CBOR. Сравнение ой не в пользу PER.
В CBOR после начального деления на major и minor type всё банально и реально достаточно эффективно (начиная уже с выноса мелких констант в отдельные типы), народ проделал серьёзную работу по изучению реальных данных в Сети и поиску оптимальных методов кодирования. При этом в отличие от PER (но аналогично BER) не потеряны типы данных (хотя бы частично), что позволяет определять заметный класс ошибок передачи.
H>Вот что есть в ASN.1, а больше я нигде не видел, это constraints. Хотя бы constrained integer и его представление в PER — гениально. Но хипстерам сложно.
Я не хипстер, но мне тоже сложно (PER в целом, продираться заново сквозь стиль описания).
Но я сейчас открыл эту секцию и не вижу ничего "гениального":
1. Оно зависит от lower bound и upper bound. А теперь что если у параметра допустимые значения, например, 0, 22, 31 и 45? Его можно впихнуть в 2 бита, но по этому описанию потребуется 6.
(Это не искусственно придуманный случай. Я сейчас такие штуки вижу в реальном проекте. Там не так растянуто, конечно, но есть в одном месте, например, из ~30 возможных чисел допустимо только 10.)
2. Весь алгоритм это просто выбор между: <8 бит, 8, 16, больше. Извините, это банальность, а не гениальность.
(Или я не то смотрю? Пункт 10.5.)
3. Оно зависит от идентичности определений схемы на обеих сторонах (ну и от наличия самой схемы). Версионность не работает, или работает криво. Если было допустимо, например, 0..50 (температура воздуха для тропиков), а для умеренных широт добавили до -30 снизу — всё, lb поменялся, плавного перехода не будет.
H>P. S. Всё же про ASN.1 надо учитывать, что его делали связисты, а не кодеры. Вот посмотрите на HTTP — его делали кодеры. Зато можно подключиться к HTTP серверу телнетом и чего-то там напечатать.
Любую двоичку ты не напечатаешь телнетом. Тем не менее, как видим по всей теме, временами она очень нужна.
А HTTP делали не кодеры, а высоколобые грамматисты — причём того стиля, который не укладывается в стандартные в остальном мире грамматические подходы. Я парсил SIP (идентичен по стилю и почти по деталям), это не укладывается в привычные LL/LR, по факту это нерекурсивный PEG на классах символов. Кодеры бы такое не придумали.
S>The article mentions that Google was able to boost user engagement in Google Maps by reducing the page weight from 100KB to 80KB.
S>Э-э?.. Только что проверил, чуть меньше шести метров. Просто google.com/maps, гугл-эккаунта у меня нет, масштаб всей Земли.
Это ж про google maps образца 2006 года. Возможно это даже про тогдашнюю мобильную версию речь.
The performance of websites and the impact that has, has been well documented over the years. In 2007 Amazon reported that for every 100 ms increase in load time of Amazon.com their sales decreased by 1%. Google also reported similar results in 2006 with their Google Maps product. Google found that by reducing the size of the page from 100KB to 80KB, their traffic shot up by 10% in the first week and then 25% in the following three weeks.
Здравствуйте, Kernan, Вы писали:
N>>ASN.1 был пионерской разработкой. Крайне сложный язык описания структур, неэффективные кодировки в двоичку, и всё такое. K>Он крайне сложный только для тех кто не знаком с матчастью теории компиляторов.
Я сейчас не найду ссылок, но авторитетно утверждалось, что даже с инструментальными средствами компиляции были заметные проблемы работы с ним.
Далее, затраты кода и памяти на полную реализацию были неподъёмны для большей части потенциальных применений 80-х и начала 90-х.
Коммерческие реализации стоили безумных денег. Свободные реализации только начинались и были багованными. Сейчас есть более-менее нормальные реализации, но это ж сейчас, когда ресурсов в ~1000 раз больше.
Ну а "матчасть теории компиляторов" в полном объёме и сейчас мало кому понятна.
K> Понятно, что АСН.1 был создан под задачи того времени и людьми которые были в наличии, а это были не самые плохие спецы .
Внизу — может быть. Вверху — ой нет, или по крайней мере они решали не задачу сделать эффективное решение, а — сделать своё решение и необязательно дёшево ;\
K> Кроме BER есть PER где упаковка идёт на битовом уровне, поэтому там была нужна эффективность, её можно было использовать.
И она включает жёсткую зависимость от наличия схемы и её согласованности между всеми участниками.
BER гибче, SNMP разбирается вообще без схемы, на интуиции — почему он оказался в итоге чуть ли не единственным приложением ASN.1, которое стало массовым. (X.509 это заметно позже, и там тоже BER (в виде DER), но не PER.)
N>>Это подвиг, но много моментов решено неоптимально. K>Например?
В CBOR видно, что целые до ±31 представляются одним байтом. Это очень частый случай и он оптимизирован. BER требует 3 байт на такое. PER — один байт или меньше, но тип при этом не указан, получается жёсткая зависимость от согласованности схемы. Много других аналогичных оптимизаций CBOR на сокращение объёма представления в полтора-два раза, при сохранении указания типа данного, для корректной синхронизации и полиморфизма.
N>>Если говорить о чём-то современном близкого типа, то это CBOR. У него плотность представления в двоичке выше раза в два, чем у BER. Текстовое представление почти полностью соответствует JSONʼу, то есть понятно всем по современным подходам. K>Возможно, будущий кандидат для замены json. Хотя у нас всегда был бинарный xml как бы сам xml ненавидели.
N>>Но всё же, как сказал ТС, люди занимаются фигнёй вместо главного... K>А чем они должны заниматься? Мне вот кажется мы скоро начнём входить на новый виток оптимизации бесконечных джейсонов и текста чтобы не грузить сервера лишним трафиком и разбором. Сразу все вспомнят как деды проектировали системы, про бинарные протоколы, про CORBA, и про другие технологии переосмыслив их в текущих реалиях лишь бы уменьшить нагрузку на железо, трафик и управление системами. Это же надо, люди когда-то боролись с оверхедом IP заголовков придумав ROHC но всё про##&*@ тупо добавив текст во всех протоколах выше транспорта.
RoHC есть там где я сейчас, но там транспорт голоса/видео занимает заметную часть.
А как пример бинарного протокола с массой оптимизаций это QUIC, который скоро дойдёт, наверно, до 50% мирового трафика.
А "чем заниматься" — ну упоминалось же про 20MB скриптов? Их тоже загрузить надо (не знаю, что там с кэшированием в браузере, но явно тоже работает не всегда).
Здравствуйте, Andir, Вы писали:
S>>Э-э?.. Только что проверил, чуть меньше шести метров. Просто google.com/maps, гугл-эккаунта у меня нет, масштаб всей Земли. A>Это ж про google maps образца 2006 года. Возможно это даже про тогдашнюю мобильную версию речь.
A>
The performance of websites and the impact that has, has been well documented over the years. In 2007 Amazon reported that for every 100 ms increase in load time of Amazon.com their sales decreased by 1%. Google also reported similar results in 2006 with their Google Maps product. Google found that by reducing the size of the page from 100KB to 80KB, their traffic shot up by 10% in the first week and then 25% in the following three weeks.
Здравствуйте, vsb, Вы писали:
vsb>У меня ничего не тормозит. Не знаю, что там за мудрецы.
просто хорошее соединение с интернет.
я недавно в Калифорнии с ооочень слабой и не стабильной мобильной связью пытался открыть сайт AT&T, что бы как раз интернет провести... я все проклял сайт настолько перегружен всякой х*йней, что зависает намертво. вообще ничего не грузится. ну нельзя же так я же туда иду, потому что у меня нет интернета и хочу его провести мне нахер не нужны все эти их рюшки (я специально пробовал открывать RSDN — все грузилось на ура )
Здравствуйте, baxton_ulf, Вы писали:
_>просто хорошее соединение с интернет.
А у кого оно сейчас плохое?
_>я недавно в Калифорнии с ооочень слабой и не стабильной мобильной связью пытался открыть сайт AT&T, что бы как раз интернет провести... я все проклял сайт настолько перегружен всякой х*йней, что зависает намертво. вообще ничего не грузится. ну нельзя же так я же туда иду, потому что у меня нет интернета и хочу его провести мне нахер не нужны все эти их рюшки (я специально пробовал открывать RSDN — все грузилось на ура )
Ну не знаю, что там в Калифорнии. У меня в деревне дом, там 4G даёт 10-50 мегабитов. И пинг вполне пристойный. Думаю, у большинства людей так. Оптимизируют под большинство.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, baxton_ulf, Вы писали:
_>>просто хорошее соединение с интернет.
vsb>А у кого оно сейчас плохое?
есть блайнд-споты, в одном из таких я и оказался
_>>я недавно в Калифорнии с ооочень слабой и не стабильной мобильной связью пытался открыть сайт AT&T, что бы как раз интернет провести... я все проклял сайт настолько перегружен всякой х*йней, что зависает намертво. вообще ничего не грузится. ну нельзя же так я же туда иду, потому что у меня нет интернета и хочу его провести мне нахер не нужны все эти их рюшки (я специально пробовал открывать RSDN — все грузилось на ура )
vsb>... Оптимизируют под большинство.
о, это теперь называют "оптимизируют", как я отстал от жизни
Здравствуйте, L.K., Вы писали:
LK>А насчёт JSON->Messagepack я вообще не понял смысла. Что мешало тот же самый JSON хранить сжатым gzip-ом? LK> А при передаче по сети JSON сожмётся веб-сервером.
Ты статью то читал? Они ж попробовали, получили 10% уменьшения, "продуктовый эффект незначительный".
Здравствуйте, Shtole, Вы писали:
S>Просто вы хорошо думаете о людях. Вы думаете, это олимпиадники, не набравшиеся мудрости. А я думаю, они достаточно мудры, чтобы за свою деструктивную деятельность получать очень хорошие деньги
Это так не работает. Нет, тут именно хороший технический бэкграунд и очень плохое взаимодействие с продактами. Чего то там наоптимизировали, получили отличные циферки, подстелили вумные исследования про латентность, а вот про продукт свой забыли.
Здравствуйте, netch80, Вы писали:
N>3. Оно зависит от идентичности определений схемы на обеих сторонах (ну и от наличия самой схемы). Версионность не работает, или работает криво.
Серьезно? Тогда можно смело в помоечку.
N>Я парсил SIP (идентичен по стилю и почти по деталям), это не укладывается в привычные LL/LR, по факту это нерекурсивный PEG на классах символов. Кодеры бы такое не придумали.
Это смотря какие кодеры. Те которые знают про LL/LR — возможно, хотя при ручном раскладывании не особо сложно в особо тонких местах разруливать конфликты рукопашным кодом. А вот те которые не знают — легко выдадут что угодно отплясывания от рукопашного жопорукого кода парсера (т.е. грамматика вообще не проектируется, просто пишется сразу код).
Здравствуйте, Kernan, Вы писали:
K>А чем они должны заниматься? Мне вот кажется мы скоро начнём входить на новый виток оптимизации бесконечных джейсонов и текста чтобы не грузить сервера лишним трафиком и разбором
Это тебе в теории так кажется. А на практике особой разницы между JSON+gzip и каким нибудь MessagePack нет ни по памяти, ни по цпу, ни по трафику. Основная паства бинарных протоколов это всякая дохлая мелочь типа клиентов IoT, где даже 3 копейки — деньги.
K>про CORBA
Шо, опять OORPC? Нафига? Еще недостаточно шишек набито граблями?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это тебе в теории так кажется. А на практике особой разницы между JSON+gzip и каким нибудь MessagePack нет ни по памяти, ни по цпу, ни по трафику.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>Я парсил SIP (идентичен по стилю и почти по деталям), это не укладывается в привычные LL/LR, по факту это нерекурсивный PEG на классах символов. Кодеры бы такое не придумали. НС>Это смотря какие кодеры. Те которые знают про LL/LR — возможно, хотя при ручном раскладывании не особо сложно в особо тонких местах разруливать конфликты рукопашным кодом. А вот те которые не знают — легко выдадут что угодно отплясывания от рукопашного жопорукого кода парсера (т.е. грамматика вообще не проектируется, просто пишется сразу код).
То есть разбирать такое ты не пробовал. Иначе бы не выдавал комментарии, как тот программист летящим на воздушном шаре.
N>>3. Оно зависит от идентичности определений схемы на обеих сторонах (ну и от наличия самой схемы). Версионность не работает, или работает криво. НС>Серьезно? Тогда можно смело в помоечку.
Кажется, пора формулировать принцип "послушай НС и сделай строго ортогонально тому, что он предлагает".
. Кроме BER есть PER где упаковка идёт на битовом уровне, поэтому там была нужна эффективность, её можно было использовать.
Потом ресурсы идут на хрен пойми что. Но я не до конца дочитал.
сайт настолько перегружен всякой х*йней, что зависает намертво. вообще ничего не грузится. ну нельзя же так 
я же туда иду, потому что у меня нет интернета и хочу его провести 
мне нахер не нужны все эти их рюшки (я специально пробовал открывать RSDN — все грузилось на ура 
)
