Programming
Designing and refactoring
Go
Comments 10
0

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

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

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

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

0

А зачем нужен 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
0

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


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 таки быстрее.

0
Помимо производительности есть ещё один момент:

> It prevents its internal byte slice to escape. Like this: (*Buffer).Bytes(). So, it's immutable and can only grow or reset.
0
Хотел бы добавить, что любой вызов strconv.FormatInt или ParseInt будет в текущей реализации Go медленней, чем вручную написанный парсер или форматтер чисел из-за того, что Go не инлайнит код за пределами текущего пакета (и за счёт этого возникает как минимум оверхед на вызов функций, который можно избежать для таких простых случаев как парсинг числа)
Only those users with full accounts are able to leave comments. , please.