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