а. ну и да. при обработке JSON можно еще на мемори аллокации упасть. поэтому читать реально было только в stream/flow режиме. иначе мог произойти пик потребления памяти и всё падало. подключиться к докеру решения на сервере и поглядеть observer'ом чего там происходит, естественно нельзя. поэтому сама отладка того, что происходит на сервере, но не происходит у тебя - весьма неиллюзорна

да и скорость работы решения на сервере иногда оказывалась ниже, чем у себя дома. причем я несколько дней искал причину, почему теряется производительность на скорость ответа. а потом оказалось, что у меня на хостовой машине и в докере немного отличаются версии Erlang и ерланг, что в докере не пересобирал beam'ы, а брал мои, но из за разницы в версиях, видимо, происходили какие-то накладки. ничего не падало, но работало очень медленно (лучше бы упало). порешалось, когда совместными усилиями догадались очищать _build перед сборкой докер образа решения перед загрузкой )))

в реальности же скорость работы решения отличалась. Сишники определили. Выводили в консоль информацию о сервере и выяснилось, что серверов два. Один побыстрее, второй помедленнее )))

и это еще далеко не всё...
в общем, конкурсы интересные. рекомендую

Структура известна?

конечно

Тогда возможно имеет смысл из жсона в бинарь переливать

я так и сделал

бинарь с диска вгружается и парсится почти мгновенно

я с подобной проблемой столкнулся при чтении mp4.

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

но

весь этот хайлоад перфоманс вызывает легкое уныние

к реальной практике отношения мало

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

в принципе одна машина - это не хайлоад

условия задачи и критерии оценки такие, что сможет победить только нативное решение с ручным укладыванием структур в памяти.

структуры ерланга определенно жирнее из за, как бы, дескрипторов.

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

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

еще с прошлого года предлагалось считать штраф, как это происходит в реале - при превышении SLA времени на ответ.