JD
хмм, поясни плиз, о каком прокси идёт речь?
js Proxy объект.
Size: a a a
2018 December 19
JD
хмм, поясни плиз, о каком прокси идёт речь?
Конвертация с ascii за линейное время будет, быстрее чем в uft8
RS
js Proxy объект.
хмм, чёт я не въехал
JD
хмм, чёт я не въехал
Вот тут у меня смотри, lazy парсер. https://github.com/reklatsmasters/btparse
RB
проблема по сути своей банальна:
есть у нас структура, из:
1х float64
1х uint32
1x uint16
3х uint32 флагов
и 3х unicode строк дин. размера
JSON для этого подходит так себе, кодировка и декодировка не бесплатные да и схемы у него нет, а тут схема заранее известна, даже декодер можно кодогенерировать под конкретный протокол.
есть у нас структура, из:
1х float64
1х uint32
1x uint16
3х uint32 флагов
и 3х unicode строк дин. размера
/* Message structure:
step field len offset
64 a 8 0
32 i 4 8
n_l 4 12
e_l 4 16
s_l 4 20
16 c 2 24
8 n n_l 26
e e_l 26+n_l
s s_l 26+n_l+e_l
*/
и приходит нам это по сети. Мы это хотим пропарсить и получить object, за кратчайшее время.JSON для этого подходит так себе, кодировка и декодировка не бесплатные да и схемы у него нет, а тут схема заранее известна, даже декодер можно кодогенерировать под конкретный протокол.
1. Интересно узнать что это, где применяется, пример реальных данных, если есть возможность
2. Каков размер одного сообщения
3. Насколько большой поток сообщений
4. Что значит "жутко медленный" для TextDecoder в цифрах
2. Каков размер одного сообщения
3. Насколько большой поток сообщений
4. Что значит "жутко медленный" для TextDecoder в цифрах
RS
1. Интересно узнать что это, где применяется, пример реальных данных, если есть возможность
2. Каков размер одного сообщения
3. Насколько большой поток сообщений
4. Что значит "жутко медленный" для TextDecoder в цифрах
2. Каков размер одного сообщения
3. Насколько большой поток сообщений
4. Что значит "жутко медленный" для TextDecoder в цифрах
1. конкретной задачи нет, проект скорее эксперементальный и задача получить наиболее эффективный способ передачи данных.
2. размер может сильно вариировать, от одной строки до вложенного графа 4 уровней
3. в данном контексте это опять-же не особо релевантно, ибо речь о максимально достижимой эффективности нежели о решении конкретной проблемы
4. https://jsperf.com/binary-vs-json в этом бенчмарке я вроде не допускал ошибок в его использовании, и тем не менее он сильно проиграл. Я не уверен насколько бенчмарк правдив, но данная разница коллосальна
2. размер может сильно вариировать, от одной строки до вложенного графа 4 уровней
3. в данном контексте это опять-же не особо релевантно, ибо речь о максимально достижимой эффективности нежели о решении конкретной проблемы
4. https://jsperf.com/binary-vs-json в этом бенчмарке я вроде не допускал ошибок в его использовании, и тем не менее он сильно проиграл. Я не уверен насколько бенчмарк правдив, но данная разница коллосальна
RS
у меня в мозгах не укладывается тот „факт“, что generic textual protocol эффективнее статичного бинарного. Это кажется бредом.
по всей логике JSON должен быть гораздо менее энергоэффективен нежели подогнанный под задачу бинарный протокол. И на сервере это действительно так, стоимость marshalling’а & unmarshalling’а JSON’ок ощутима. А вот на клиенте создаётся такое впечатление что мы на протяжении десятилетия шли не в то направление
по всей логике JSON должен быть гораздо менее энергоэффективен нежели подогнанный под задачу бинарный протокол. И на сервере это действительно так, стоимость marshalling’а & unmarshalling’а JSON’ок ощутима. А вот на клиенте создаётся такое впечатление что мы на протяжении десятилетия шли не в то направление
RS
поэтому я и задался эксперементальной задачей доказать, что бинарный протокол гораздо энергоэффективнее. Но пока-что видимо без успеха в мире JS. С другой стороны возможно бенчмарк совершенно не правдоподобный, этот момент пока ещё не ясен, ибо современный JS движок та ещё коварная стерва со своими JIT оптимизациями.
RB
1. конкретной задачи нет, проект скорее эксперементальный и задача получить наиболее эффективный способ передачи данных.
2. размер может сильно вариировать, от одной строки до вложенного графа 4 уровней
3. в данном контексте это опять-же не особо релевантно, ибо речь о максимально достижимой эффективности нежели о решении конкретной проблемы
4. https://jsperf.com/binary-vs-json в этом бенчмарке я вроде не допускал ошибок в его использовании, и тем не менее он сильно проиграл. Я не уверен насколько бенчмарк правдив, но данная разница коллосальна
2. размер может сильно вариировать, от одной строки до вложенного графа 4 уровней
3. в данном контексте это опять-же не особо релевантно, ибо речь о максимально достижимой эффективности нежели о решении конкретной проблемы
4. https://jsperf.com/binary-vs-json в этом бенчмарке я вроде не допускал ошибок в его использовании, и тем не менее он сильно проиграл. Я не уверен насколько бенчмарк правдив, но данная разница коллосальна
Смотря какая эффективность нужна. Если минимизация передаваемых данных - возможно. Например, нам нужно передавать очень много событий для условной игры (движение мышью, клики, время события). Если передавать строкой, то 13 байт на время, 8 байт (xxxx*xxxx) на координаты, 1 байт на событие, т.е. 22 байта на одно событие, а если в бинарном то 13 байт достаточно. Т.е. тут преимущество почти в два раза. Но со строками мне не понятно, если они нужны и будут занимать основную часть данных, то экономия 10-20 байт вообще не влияет на размер пакета в процентном соотношении.
По поводу скорости парсинга. Я понимаю что серверу может быть нужно парсить сотни тысяч сообщений в секунду. Но клиенту зачем? Вот я взял среднее JSON сообщение весом 1.5 Кб, за 1 секунду JSON.parse() разбирает 50 тыс. таких сообщений. И это без всяких воркеров и на одном ядре.
Если одной пачкой 10к сообщений:
Time: 151.4000 ms, size: 5.30 Mb.
Даже не представляю зачем на клиенте может быть нужно такое. Мне кажется это никогда не будет узким местом. Было бы интересно услышать если у кого-то есть примеры где это хоть сколько-то может повлиять на производительность.
По поводу скорости парсинга. Я понимаю что серверу может быть нужно парсить сотни тысяч сообщений в секунду. Но клиенту зачем? Вот я взял среднее JSON сообщение весом 1.5 Кб, за 1 секунду JSON.parse() разбирает 50 тыс. таких сообщений. И это без всяких воркеров и на одном ядре.
Если одной пачкой 10к сообщений:
Time: 151.4000 ms, size: 5.30 Mb.
Даже не представляю зачем на клиенте может быть нужно такое. Мне кажется это никогда не будет узким местом. Было бы интересно услышать если у кого-то есть примеры где это хоть сколько-то может повлиять на производительность.
ҪҸ
SV
В файрфоксе настолько быстрее.
VR
я, может, не очень умный, но 95% задач бинарных сообщений на фронте может решить либо msgpack, либо протобуф
AF
либо свой метод
AF
собственный
ҪҸ
он и с протобафом/мсжпаком будет свой собственный
ҪҸ
других нет
AF
собственный
AF
not invented here