Я работаю над своим первым ящиком (aws-elb-abacus, пока ничего на master, но уже близко). Это действительно тривиальная проблема для решения, и я уже запустил эквивалентное решение, написанное на Go, в производство, что сделало его идеальной проблемой для моего первого ящика.
Важная часть кода анализирует набор значений, разделенных пробелами (документы AWS), а затем преобразует некоторые значения в более точные представления для дальнейшей обработки. Сейчас проделано много работы над струнами.
По совпадению, я читал то, что писали другие, после обзора кодовой базы Rust, и наткнулся на следующее утверждение о работе со строками.
Don’t use to_string on strs; it’s generic, which makes it slow. Prefer into or to_owned.
Был ответ от Стива Клабника, он из Rust Book, который объяснил немного больше.
To elaborate here a bit, it’s not exactly that generics are slow, it’s that it could be faster if it took advantage of it being &str specifically, which it can’t do. Yet…
- "источник"
Я использовал to_string для всего в моем ящике (и всего, что я написал на Rust на сегодняшний день), поэтому мне было немного любопытно.
Быстрый поиск в Google и небольшое чтение привели меня к этим вопросам и ответам, в которых было лучшее объяснение деталей.
You should always be using to_owned(). to_string() is the generic conversion to a String from any type implementing the ToString trait. It uses the formatting functions and therefor might end up doing multiple allocations and running much more code than a simple to_owned() which just allocates a buffer and copies the literal into the buffer.
Совершенно разумно, но насколько это важно в реальном мире? Пришлось провести некоторое тестирование.
Я тестировал свой код, когда работал со своим ящиком, поэтому мне было достаточно просто заменить вызовы методов и запустить тесты.
Я проводил сравнительный анализ двумя методами. Первый тест использует поддержку тестов Rust nightly. Обычно я не сторонник такого рода сравнительного анализа. В большинстве случаев результаты являются абсолютной ерундой и не влияют на производственные результаты либо потому, что эталонный тест ошибочен, либо потому, что разработчик с самого начала тестирует неправильный участок кода. Но мне интересно узнать о встроенной поддержке тестирования в Rust, и я хочу отслеживать развитие этой функции по мере продвижения Rust. Что может быть лучше, чем иметь собственный код?
Вот результаты.
using to_string: test bench_parse_line ... bench: 2,299 ns/iter (+/- 259) using to_owned: test bench_parse_line … bench: 2,097 ns/iter (+/- 348)
Похоже, что производительность значительно выросла - примерно на 9%.
Я запускал его несколько раз, и каждый раз цифры примерно одинаковые.
Но, опять же, я не фанат микротестов. Так как насчет теста в реальном мире?
На протяжении всей разработки я использовал инструмент командной строки, который написал, чтобы использовать ящик с реальным набором журналов AWS ELB.
Это результаты изменения с to_string на to_owned для реального набора файлов.
using to_string: Processed 121 files having 9340036 records in 32010 milliseconds. using to_owned: Processed 121 files having 9340036 records in 28462 milliseconds.
Переход на to_owned привел к увеличению производительности примерно на 11%. Это реальное время, которое потребуется для работы в производственной среде, что для меня гораздо важнее, чем микротест. При этом результаты обоих тестов на удивление близки, и инструмент CLI на данный момент не делает ничего больше, чем микротест.
Цифры разумны, учитывая заявленные причины использования to_owned вместо to_string.
Я убежден, что to_owned - это правильный метод, который действительно повышает производительность программ, выполняющих большое количество преобразований строк.
Кроме того, что, возможно, более важно, я напоминаю, что проверка кода, который вы не писали, и чтение отзывов других - это действительно, очень важная часть того, чтобы стать лучшим разработчиком. Сообщество Rust преуспевает в этой области. Как правило, если кто-то отправляет запрос на проверку кода, по крайней мере, один человек, а чаще всего несколько человек, будут уделять время проверке. Я скоро отправлю запрос на проверку кода.
