но анализировать это всё дико удобно в kcachegrind

и очень мало нагрузки по сравнению с обычными подходами. erl_tracer позволяет ещё больше тюнить процесс трассировки,но я пока не до конца въехал в его концепт. looking_glass его как раз использует

так что буду играться

а fprof вообще не применим если гоняешь на активной системе плюс нереальные помехи создаёт

звучит круто

ещё цитата из looking_glass: Looking Glass can also be used to profile Erlang processes based on the messages they send. It can help you detect which processes are the most busy and is able to generate graphs and sequence diagrams to help you debug complex issues

ребят, у кого будет немного времени почитать... http://allyst.github.io/opensource/llsn/ru/ покритикуйте плиз формат данных. я его запилил 6 лет назад. подумываю тут его немного реанимировать, в чувства привести и в одном проекте поюзать.

если интересно посмотреть потрогать, есть реализации на ерланге и голанг, на моем гитхабе.

а чем оно лучше msgpack (за исключением хвостовой упаковки, которая может быть реализована  на логическом уровне)?

в том смысле есть ли потенциал сделать его быстрее и компатктнее? так-то вроде тоже самое

ох, давно это было, когда ресерчил эту тему. я тогда решал задачу найти формат с возможностью кодирования динамических структур, в том числе древовидных. на одноразовых сообщениях практически любой формат подходил. но когда требовался кейс закодировать кусок с деревом структур, то на одном кодировании типа данных на каждом элементе уходило сильно много объема. плюс там еще что-то было. с ходу уже не вспомню. ща поднатужусь, может вспомню чего, отпишусь)

т.е. если нужно гнать стрим структур, то с моим форматом она кодировалась только один раз, дальше только данные шли один за другим.

где-то лежал бенч. массив чисел. llsn давал упаковку лучше, чем зип джейсона. но на этом кейсе

но оно и понятно, в llsn числа упаковываются оч плотно.

ну, наверно есть смысл показать сравнеине с другим популярным безсхемным форматом (типа msgpack). как я понимаю у тебя есть расширения "прикладного уровня" типа дата, хвостовая упаковка. но при этом есть и проблемы типа ограничения на размер inline строки и  отсутствие реализаций.

я же написал, реализовано на ерланге и голанге

ну да, я и говорю - нет реализаций )

ааа, ну на все языки меня не хватит))

ну ты спрашиваешь - есть ли смысл реанимировать. вот и прикидывай чтобы взять формат обмена реализаиця для которого есть только в двух языках (для примера смотри msgpack https://msgpack.org/)  надо сильно наверно лучше быть

это формат для конкретных задач, ближе к стримовым, где нужно, напрмер уметь частично декодировать, только первые несколько пакетов, чтобы по какому-то значению роутить пакеты куда-то в стороно (для этого хвостовая упаковка и была задумана)