Блог*

#prog #go

В Go недавно (кстати, thanks @go_perf) внесли изменение: "strconv: optimize Parse for []byte arguments". Что же там такого сделали? Читаем:

When one has a []byte on hand, but desires to call the Parse functions,
the conversion from []byte to string would allocate.

    var b []byte = ...
    v, err := strconv.ParseXXX(string(b), ...)

This changes it such that the input string never escapes from
any of the Parse functions. Together with the compiler optimization
where the compiler stack allocates any string smaller than 32B
this makes most valid inputs for strconv.ParseXXX(string(b), ...)
not require an allocation for the input string.

<...>

Previously, this was not possible since the input leaked to the error,
which causes the prover to give up and instead heap copy the []byte.
We fix this by copying the input string in the error case.
The advantage of this change is that you can now call strconv.ParseXXX
with a []byte without allocations (most times) in the non-error case.
The detriment is that the error-case now has an extra allocation.
We should optimize for the non-error path, rather than the error path.

Так а для чего это в принципе понадобилось? Дело в том, что строки в Go — это единственный, помимо числовых, неизменяемый тип данных. Не смотря на то, что представление строки — это префикс представления слайса (указатель и длина) и, по идее, конвертация из одного в другое должна быть дешёвой, в общем случае это делать небезопасно: этот слайс могут менять где-то в другом месте и таким образом инвалидировать иммутабельность строки. Именно поэтому конвертация из []byte в string в общем случае должна аллоцировать память. Да, в Go есть escape analysis, но он тут не работал из-за сомнительного дизайн-решения: ошибка парсинга включает в себя текст разбираемой строки.

(Кстати, функции для парсинга почему-то хоть и возвращают всегда *NumError — и даже пишут об этом в документации — но скрывают это в типах за error)

Как и описано в изменении, на error path строка теперь копируется. Но причём тут extra allocation, если аллокация и так раньше была? Дело в том, как именно это копирование строки реализовано — через написанную на месте функцию cloneString:

func cloneString(x string) string { return string([]byte(x)) }

И тут действительно две аллокации: из строки в слайс и из слайса в строку — на одну больше, чем до изменения. Казалось бы, можно использовать strings.Clone, которая ровно для этого и предназначена (и, кстати, которая эксплуатирует одинаковое представление префикса слайса и строки). Но нет, как написано в комментариях, транзитивной зависимостью strings является пакет unicode с объёмными таблицами, добавляющими размер итоговому бинарю.

Для сравнения: в Rust операция парсинга (которая, между прочим, называется одинаково вне зависимости от разбираемого типа и даже может поддержать кастомный тип через реализацию FromStr) проводится на &str. Какими бы не были байты на руках, их всегда можно привести к &[u8], ссылке на байтовый слайс, а их, в свою очередь, через std::str::from_utf8 к &str. Это не совсем дёшево в том плане, что требует прохода по всем байтам для того, чтобы убедиться, что они корректно закодированы в UTF-8, но всё же не требует аллокации в куче. Иммутабельность ссылки на пару с borrow checker-ом гарантируют, что во время вызова str::parse нижележащие байтики не будут изменены. При этом этот запрет на изменение действует лишь на время жизни ссылки, а потому ничто не мешает сделать это со ссылкой на некоторый изменяемый буфер.

TL;DR: отсутствие иммутабельности в Go (как, впрочем, и странные решения в стандартной библиотеке) напрямую ведёт к необходимости трейдоффов по производительности.

👍9

780 viewsedited 19:14