Комментарии 26
А можешь посоветовать, на какие источники стоит подписаться на тему Go, на вроде Teiva Harsanyi из начала статьи?
Я подписан на golangweekly.com, слежу за reddit.com/r/golang, ну и статьи про Go часто проскакивают на Hacker News.
Еще можно следить за каналом News на российском Golang коммюнити Slack-е.
А в англоязычном Golang community есть канал #performance
. :)
https://gophers.slack.com
И всем, кто добавил ссылки ниже, тоже)
golang-ru.slack.com
А если нарушить красоту и правила, и сделать часто аллокируемые переменные с буфферами глобальными (хотя бы с точностью до горутины), сколько ещё можно выиграть?
Например, если вы считываете что-то с файловой системы или делаете много сетевых вызовов, то для получения большей производительности следует использовать большее количество горутин, чем у вас ядер.
Не могу понять, почему так?
в любом языке в concurrent решение не быстрее обычного, при условии что они выполняются на одном ядре.
в любом языке регулярки — очень жирные, потому что они рассчитаны на гибкость.
пример с trim — тоже показывает что обобщенное решение, не быстрее конкретного.
Пожалуй, самый наглядный пример — это поиск элемента перебором, или бинарным поиском — зная, что все элементы упорядоченны, мы можем в разы ускорить поиск элемента
Если у вас все IO блокирующее, то никакого ивентлупа (poll/select) вы не сделаете. Следовательно никакой конкурентности вы не получите.
Если под «обычным» решением мы понимаем простое однотредовое решение без использования файберов/зеленых тредов/корутин, то неблокирующее IO никак его быстрее не сделает.
Потому что супероптимизаторы никто в 21 веке ещё не написал. Немного трудная задача
вот сегодня была задача на го… есть входный интерфейс, изначально известно — это json, при чем в 1 уровень, нет вложенных объектов или массивов, секс начался, когда при сведении, значение 1 (ИД, который везде проходил как integer), внезапно начал при сведении типов определяться как float64, при чем с плавоющей точкой в пределах программы вообще нед ни действий не объявлений… вот и пожалуйства… работа над одной задачой призвела до анализа всей программы, день пришлось провозиться чтобы все в порядок привести…
друг сегодня книгу у меня увидел (заходил в гости пива попить), говрит "*бать, анси Си — разве си сегодня кому то нужен?" (интересовался в комерческих целях) — отвечаю: — нужен, си — о*енный язык, но сложный… и правда…
смотрю на рожденные языки в диапазоне последных 10-ти лет, и ниодин не нашел, который бы не позволял создавать программы с неправильными адресациями, некорректными указателями и т.п… зачем тогда писать на «современных ЯП», если можно писать на си, или си++, но такие программы, покрытые тестами, обыычно еффективней, и поведение их максимально приближено к ожилаемому?
Ранее мы отказались от конкурентности на уровне обработки линий,
Так линий или строк?
в моей практике была необходимость обработать большой файл (несколько гб) — читал его го-рутинами используя seek, это правда помогло, но выиграш только на больших объемах… правда можно ускориться в несколько раз.
Подобные изменения — это уже не рефакторинг.
Рефакторинг программы на Go: ускорение в 23 раза