Комментарии 18
Статья огонь. Правда не хватает еще видео с доклада.
А можете пояснить для новичка в Go, почему если нужна скорость не проверяли
gccgo, насколько он усокряет код, а также не использовали встроенный в него
профилирофшик (gprof)?
На данном этапе основной компилятор для Go меня устраивает. Лучшего ответа у меня нет.
Основной компилятор на то и основной. Вся разработка идет в нем. А Gccgo — это так, развлечение Ян-а, по моему мнению.
Основной компилятор на то и основной. Вся разработка идет в нем. А Gccgo — это так, развлечение Ян-а, по моему мнению.
С ним все не так однозначно. По идее, он может генерировать более эффективный код, но он не умеет в Escape Analysis, что плохо сказывается на GC производительности. Да и действительно поддержка gccgo хуже, он отстает на несколько версий языка. Сколько смотрел про оптимизацию Go, не особо даже упоминают gccgo. В сфере применения Go главная проблема это как облегчить работу GC.
Во времена go 1.3-1.4 скомпилированный gccgo вариант на имевшихся у меня приложениях давал ощутимо более медленный код. С тех пор, правда, не сравнивал.
НЛО прилетело и опубликовало эту надпись здесь
Пора делать новую статью по версии 1.20 Интересно насколько изменилось распределение памяти в Go и Escape-анализ? Не далее как на выходных занимался тем же самым через runtime.MemStat. Внезапно обнаружил что даже при создании локальных переменных в функции и при передаче их в параметрах .. растет счечтик аллокаций в куче и количество размещенных объектов. Но пока ещё только разбираюсь, может сам не верно проанализировал результат. Хотелось бы почитать тех, кто уже разбирается в этом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Профилирование и оптимизация программ на Go