Комментарии 6
Впервые вижу такую запись [:nodeSz:nodeSz], можете кинуть ссылкой на ее пояснение?
Напоминает истории из мира Java, где для обхода отсутствия value types выделяют сырой буфер и менеджат вручную. Забавная борьба против сборщика мусора.
Если же серьёзно, почему не взять для critical path более приспособленный к этому язык? Отдать туда данные в одном буфере и получить результат в другом. Заодно уменьшить накладные расходы из-за CGo вызовов.
Если же серьёзно, почему не взять для critical path более приспособленный к этому язык?
Потому что у Go высокий оверхед на вызовы функций по FFI. Не факт, что выигрыш от использования другого языка этот оверхед покроет.
Так автор оригинала на это и нарвался. И героически запилил pool allocator. В результате у него всё равно оверхед. Логичней было бы изолировать critical path таким образом, чтобы отдать туда одним вызовом сразу большой пак работы. И вместо пачки вызовов — формирование входного буфера плюс один длинный вызов, на фоне времени которого оверхед будет мизерный.
Ручное управление памятью в языке Go