Комментарии 10
Спасибо за перевод! Очень интересно!
Спасибо, хорошая подборка. Про маршалинг/демаршалинг ХМЛ бы добавить еще. Там часто данные покрупнее бывают.
Такое часто встречается в других пакетах стандартной библиотеки: см. strconv.AppendFloat против bytes.NewBuffer.
Скорее всего имеется ввиду strconv.FormatFloat
Перевод режет глаза прямыми переводами вроде "базовая линия" или "карта". Чтобы такого не случалось, желательно знакомиться с предметной областью и ее терминами и устоявшимися выражениями. Например, в том же DS так и говорят — бейзлайн, и все понимают о чем речь!
А зачем нужен 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 — в другом.
Если вам в итоге нужен именно тип string, то это должно работать быстрее, чем использование string(bytes.Buffer.Bytes()). В остальных случаях разницы не должно быть, или она будет в пользу bytes.Buffer
У Вас второй бенч кривой, не может быть 0 аллоков, если используются строки (хотя бы в итоге)
А по существу вопроса — strings.Builder как раз и сделали как более оптимизированную замену bytes.Buffer
А по существу вопроса — strings.Builder как раз и сделали как более оптимизированную замену bytes.Buffer
НЛО прилетело и опубликовало эту надпись здесь
Хотел бы добавить, что любой вызов strconv.FormatInt или ParseInt будет в текущей реализации Go медленней, чем вручную написанный парсер или форматтер чисел из-за того, что Go не инлайнит код за пределами текущего пакета (и за счёт этого возникает как минимум оверхед на вызов функций, который можно избежать для таких простых случаев как парсинг числа)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простые методы оптимизации программ Go