Комментарии 21
Производительность в большинстве случаев не имеет значения
нет, суть дела не в этом!
и дело не в Go, а во "всем бизнесе в целом". почему? потому, что
Ради этого места реального бизнеса АБСОЛЮТНО нет смысла стараться. Хуже дурака - только дурак с инициативой!
Нет смысла стараться нигде, кроме узкого места (bottleneck). Но развальцуете бизнесу bottleneck -- он сразу пойдет веселее!
Bottleneck может возникнуть если люди всё-таки старались писать код который должен работать быстро и возможно даже наладили нагрузочное тестирование. Если изначально в проекте никто этим не заморачивался, то тормоза размазаны по всему проекту и так просто от них не избавиться. Если архитектура кривая, то проще переписать, чем пытаться исправить в существующем.
Bottleneck может возникнуть если люди всё-таки старались
bottleneck - это не оскорбление :) он есть всегда.
это как скорость эскадры определяется скоростью самого медленного корабля.
тормоза размазаны по всему проекту
практика показывает, что в реальных проектах есть только один СЕРЬЕЗНЫЙ bottleneck. максимум два.
Если архитектура кривая, то проще переписать
не бывает такой Роскоши, увы.
(в серьезных проектах)
Вообще - согласен с автором. Код в целом должен быть более простым для чтения, чем сложным, но с оптимизированным latency в 38мс вместо 40мс, хотя бы потому что на чтение такого "сложного" кода другим разработчиком явно уйдет гораздо больше времени, а еще больше времени займет рефакторинг этого кода с сохранением текущего поведения. А вообще я придерживаюсь мнения, чтоосновная проблема это обычно архитектура самого продукта.
Производительность не важна...важно время программиста....
Не идея хороша но вспоминаю ещё когда учился в институте, была задача распарсить пару тысяч эксель файлов и сделать из них базу данных.Файлы были почти одинаковы по структуре, но попадались с мелкими отличиями которые надо было отлавливать и писать обходные варианты. Так вот первая версия софтины парсила их около 40-50 минут, а потом напоролась на ошибку и упала. После исправление ошибки было ещё 60 минут и падение на другом файле. Но после небольшой оптимизации(две дополнительные строчки) все файлы начали парсится за 2-3 минуты. И через 20 минут уже все файлы парсились на отлично. Если бы не оптимизация отладка заняла бы часов 8.
Мораль должен быть баланс.
Мы бы конечно хотели быстрые и при этом читаемые программы, и это зачастую возможно. Но когда программист начинает говорить «Я бы мог сделать это на несколько наносекунд быстрее, используя используя массив вместо словаря и вычисляя индекс с помощью младших битов ключа!», важно подумать о том, что мы отдаём взамен на наносекунды.
Об этом тоже сказано в статье)
На самом деле у меня была похожая с вашей сутуация, что нужно было парсить тысячи пользователей ВК, так еще и все это в бд сохранять. Работало больше 10 минут - точно не скажу, потому что на 10 минутах я понял, что это как-то долго) добавил горутин - все стало выполняться меньше минуты. В данном случае горутины - спасение, так как данные не взаимодействуют между собой или с одними и теми же переменными, но бывают ситуации похуже, там уже как-будто бы go сильно не спасет)
Какая-то зацикленная аргументация. На го не пишут перф-оптимизированные программы потому что он для этого не предназначен, поэтому и не надо особо оптимизировать.
И, конечно, существует много разных специализированных и встраиваемых систем, где скорость имеет значение, например: драйверы ввода‑вывода, спутники и промышленные системы управления. Я допускаю все эти исключения, но утверждаю, что эти задачи не типичны для Go.
Окей, а почему эти задачи не типичны для Go?
На го не пишут перф-оптимизированные программы потому что он для этого не предназначен
Вас же цитирую. Зачем спрашивать, если сами знаете?)
потому что у Go есть GC, а сборщик мусора в многопоточном приложении - это УБИЙЦА производительности!!!
многопоточность очень сложна, но оправдана при росте производительности.
а потом мы прикручиваем костыль, убивающий всю производительность...
за что боролись граждане??
держу пари, что вы это не знали:
by using GC, applications spend 7–82% more wall-clock time and 6–92% more CPU cycles relative to their intrinsic costs.
both Shenandoah and ZGC have worse (by factors of 10–100×) query latencies than the other three collectors!
здесь подробности https://www.linkedin.com/pulse/how-java-garbage-collection-works-sergey-derevyago-af84f
Вывод: Пиши медленный код, не гонись за скоростью
Какой код медленный, а какой быстрый?
Я бы сказал, что многие, точнее большинство, пишут нечитаемый код не с целью добиться какой-то офигенной производительности, а целью показать, какие они офигенные виртуозы и гении. Получается так себе. ЯП тут вообще не важен. В каждой новой команде приходится долго и упорно бить по рукам за такой код. Ну или если не получается, можно просто написать пару-тройку завернутых темплейтов/дженериков, и тогда уже команда начинает выть)
Согласен. В го основное время уходит на выделение памяти поэтому для ускорения достаточно не увлекаться new и go)
Пишем медленный код на Go