Простые методы оптимизации программ Go

[UncleAndy]

Спасибо за перевод! Очень интересно!

[tuxi]

Спасибо, хорошая подборка. Про маршалинг/демаршалинг ХМЛ бы добавить еще. Там часто данные покрупнее бывают.

[alecx]

Такое часто встречается в других пакетах стандартной библиотеки: см. strconv.AppendFloat против bytes.NewBuffer.

Скорее всего имеется ввиду strconv.FormatFloat

[QtRoS]

Перевод режет глаза прямыми переводами вроде "базовая линия" или "карта". Чтобы такого не случалось, желательно знакомиться с предметной областью и ее терминами и устоявшимися выражениями. Например, в том же DS так и говорят — бейзлайн, и все понимают о чем речь!

[kilgur]

А зачем нужен strings.Builder, если есть bytes.Buffer?

BenchmarkStringsBuilderJSON4-8           5000000               345 ns/op             296 B/op          7 allocs/op
BenchmarkBytesBufferJSON4-8             2000000000               0.28 ns/op            0 B/op          0 allocs/op

В обеих функциях идентичные вызовы b.WriteString, отличия только в первой строке: var b strings.Builder в одном случае, и var b bytes.Buffer — в другом.

[youROCK]

Если вам в итоге нужен именно тип string, то это должно работать быстрее, чем использование string(bytes.Buffer.Bytes()). В остальных случаях разницы не должно быть, или она будет в пользу bytes.Buffer

[zuborg]

У Вас второй бенч кривой, не может быть 0 аллоков, если используются строки (хотя бы в итоге)

А по существу вопроса — strings.Builder как раз и сделали как более оптимизированную замену bytes.Buffer

[kilgur]

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

BenchmarkStringsBuilderJSON4-8           5000000               349 ns/op             296 B/op          7 allocs/op
BenchmarkBytesBufferJSON4-8              3000000               436 ns/op             352 B/op          6 allocs/op

невелика разница… и StringBuilder таки быстрее.

[youROCK]

Хотел бы добавить, что любой вызов strconv.FormatInt или ParseInt будет в текущей реализации Go медленней, чем вручную написанный парсер или форматтер чисел из-за того, что Go не инлайнит код за пределами текущего пакета (и за счёт этого возникает как минимум оверхед на вызов функций, который можно избежать для таких простых случаев как парсинг числа)