История вопроса.
До C++11 многие реализации std::string использовали подсчет ссылок (Copy-on-Write) для совместного использования данных строки между экземплярами, что уменьшало объем памяти для копий. Однако этот подход вызывал проблемы с безопасностью потоков, когда параллельные чтения могли привести к недействительности итераторов или ссылок при изменении внутреннего счетчика ссылок. C++11 прямо запретил эту оптимизацию, требуя, чтобы константные член-функции не инвалидировали ссылки или итераторы, что потребовало новой стратегии оптимизации, чтобы смягчить накладные расходы на аллокацию в куче для коротких строк.
Проблема.
Аллокация в куче дорого стоит из-за накладных расходов синхронизации в аллокаторах и проблем с локальностью кэша. Для приложений, обрабатывающих миллиарды небольших строк, таких как парсеры JSON или обработчики сетевых протоколов, выделение памяти для последовательностей из 5-15 символов доминирует над временем выполнения. Задача заключается в том, чтобы хранить небольшие строки внутри самого объекта std::string — обычно ограниченного 32 байтами на 64-битных системах — без нарушения совместимости ABI или нарушения строгих гарантий безопасности исключений, требуемых стандартом.
Решение.
Реализации, как правило, используют объединение из трех членов для буфера хранения: char* ptr_ для массива, выделенного в куче, size_t capacity_, и char local_buffer_[N] для встроенного массива. Дискриминатор, часто закодированный в младшем значащем бите члена size_ или с использованием определенного значения емкости, определяет, находится ли строка в "режиме SSO" или "режиме кучи". Когда size() < SSO_CAPACITY, символы хранятся в local_buffer_, полностью избегая аллокации в куче. Для более крупных строк ptr_ указывает на память в куче, и local_buffer_ перепрофилируется для хранения метаданных емкости или остается неиспользуемым.
// Концептуальная реализация (упрощенная) class string { union { struct { char* ptr; size_t size; size_t cap; } heap; // Активен, когда cap >= SSO_CAP struct { char buffer[15]; // 15 символов + нуль-терминатор unsigned char size; // Упакованные метаданные, старший бит указывает на кучу } sso; // Активен, когда size < 15 } data; bool is_sso() const { return (data.sso.size & 0x80) == 0; } };
Рассмотрим приложение для высокочастотной торговли, обрабатывающее сообщения протокола FIX, содержащие множество небольших тегов (например, "35=D", "150=2"). Начальная реализация использовала std::string для хранения каждого значения тега, что приводило к миллионам аллокаций в куче в секунду и серьезным конфликтам аллокаторов, что стало узким местом для передачи рыночных данных.
Решение A: Сырые указатели в буфере. Использование указателей char* в оригинальном буфере сообщений предлагает нулевые накладные расходы на аллокацию и максимальную производительность. Однако этот подход вводит опасные проблемы с управлением временем жизни; если оригинальный буфер повторно используется или освобождается, пока данные строки все еще нужны, это приводит к ошибкам "использование после освобождения". Кроме того, это требует ручного отслеживания длин строк, увеличивая сложность кода и потенциальные ошибки.
Решение B: Пользовательский аллокатор с пулом памяти. Реализация локальных пулов памяти для потоков снижает конкуренцию аллокаторов за счет пакетного выделения. Однако это добавляет значительную сложность с шаблонами или требует полиморфных аллокаторов по всему коду. Это также не устраняет полностью накладные расходы на аллокацию, а лишь амортизирует стоимость между несколькими строками.
Решение C: std::string_view и SSO. Использование std::string_view для обработки только для чтения избегает копий, в то время как полагание на автоматический SSO std::string для сохраненных значений обеспечивает безопасность с минимальными накладными расходами. Основным недостатком является резкое падение производительности, когда строки превышают порог SSO (15-22 символа), что внезапно вызывает дорогостоящие аллокации в куче. Кроме того, перемещение небольших строк копирует данные, а не переносит указатели, что может удивить разработчиков, ожидающих семантики перемещения O(1).
Команда выбрала Решение C, переработав парсер, чтобы использовать std::string_view для временных ссылок и std::string только когда требуется постоянство. Это снизило аллокации в куче на 95% для типичных сообщений FIX, улучшив пропускную способность с 50,000 до 800,000 сообщений в секунду при сохранении надежности памяти.
Почему перемещение короткой строки, которая использует SSO внутри, выполняет копирование символов, а не перенос указателя, и как это влияет на состояние объекта, из которого был выполнен перенос?
В режиме SSO символьный массив находится непосредственно внутри объекта std::string (обычно как член внутреннего объединения). В отличие от строк, выделенных в куче, где конструктор перемещения просто передает указатель char* и обнуляет исходный объект, перемещение строки SSO требует копирования символов из внутреннего буфера источника в внутренний буфер назначения. Это необходимо, потому что исходный объект будет уничтожен, а его внутренний буфер вместе с ним; объект назначения не может указывать на память внутри источника, который будет уничтожен. Следовательно, перемещение короткой строки имеет сложность O(N), а перемещенный объект остается в действительном, но неопределенном состоянии (не пустым), все еще содержащим свои оригинальные символы до уничтожения или переназначения.
Как std::string поддерживает требование C++11, чтобы c_str() и data() возвращали нуль-терминированные символьные массивы при работе в режиме SSO, учитывая, что размер внутреннего буфера фиксирован?
Реализация обеспечивает, чтобы буфер SSO всегда был на один байт больше максимальной емкости SSO (например, 16 байт всего для строки длиной 15 символов). Когда строка длиной N (где N < SSO_CAPACITY) сохраняется, реализация записывает нуль-терминатор в позиции N в локальном буфере. Методы data() и c_str() возвращают указатель на начало этого локального буфера, когда в режиме SSO, а не указатель на кучу. Это гарантирует нуль-терминацию без дополнительных аллокаций, удовлетворяя требованиям стандарта, что c_str() возвращает const char* на нуль-терминированную строку, и с момента C++11, что data() также указывает на нуль-терминированный массив.
Почему capacity() пустого std::string может варьироваться между различными реализациями стандартной библиотеки (например, 15 против 22), и какие последствия для ABI это имеет при смешивании версий стандартной библиотеки?
Размер буфера SSO является деталью реализации (libc++ обычно использует 22 символа на 64-битных системах, используя выравнивание, в то время как libstdc++ использует 15). Этот размер зависит от того, как реализация упаковывает метаданные размера/емкости вместе с локальным буфером внутри макета объекта std::string (обычно 32 байта всего). Поскольку это не стандартизировано, смешивание бинарников, скомпилированных с различными реализациями стандартной библиотеки (например, передача std::string из библиотеки, скомпилированной с GCC, в приложение, скомпилированное с Clang), приводит к неопределенному поведению из-за несовместимых макетов памяти. Кандидаты часто предполагают, что std::string имеет стандартный ABI, но это один из наименее портируемых типов между библиотечными границами.