Какова механика оптимизации коротких строк в libС++?

Ответ 1

libС++ basic_string предназначен для sizeof 3 слов на всех архитектурах, где sizeof(word) == sizeof(void*). Вы правильно расчленили длинный/короткий флаг и поле размера в короткой форме.

какое значение __min_cap, емкость коротких строк, берет для разных архитектур?

В короткой форме есть 3 слова для работы с:

• 1 бит переходит к длинному/короткому флагом.
• 7 бит идет на размер.
• Предполагая char, 1 байт переходит в конечный нуль (libС++ всегда сохраняет конечный нуль за данными).

Это оставляет 3 слова минус 2 байта для хранения короткой строки (т.е. наибольшей capacity() без выделения).

На 32-битной машине 10 коротких строк будут вписываться в короткую строку. sizeof (string) - 12.

На 64-битной машине в короткую строку будет вписываться 22 символа. sizeof (string) - 24.

Основная цель проекта заключалась в том, чтобы свести к минимуму sizeof(string), сделав как можно больше внутренний буфер. Обоснование - ускорить перемещение конструкции и переместить назначение. Чем больше значение sizeof, тем больше слов вы должны перемещать во время перемещения или перемещения.

В длинной форме требуется минимум 3 слова для хранения указателя, размера и емкости данных. Поэтому я ограничил короткую форму теми же тремя словами. Было высказано предположение, что размер 4 слова может иметь лучшую производительность. Я не тестировал этот дизайн.

_LIBCPP_ABI_ALTERNATE_STRING_LAYOUT

Существует флаг конфигурации _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT, который перестраивает элементы данных таким образом, что "длинный макет" изменяется с:

struct __long
{
    size_type __cap_;
    size_type __size_;
    pointer   __data_;
};

в

struct __long
{
    pointer   __data_;
    size_type __size_;
    size_type __cap_;
};

Мотивацией для этого изменения является убеждение, что при первом запуске __data_ будут иметь некоторые преимущества в производительности из-за лучшего выравнивания. Была сделана попытка измерить преимущества производительности, и ее было трудно измерить. Это не сделает ухудшение производительности, и это может сделать его немного лучше.

Флаг должен использоваться с осторожностью. Это другой ABI, и если случайно смешанный с libС++ std::string, скомпилированный с другим параметром _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT, создаст ошибки времени выполнения.

Я рекомендую, чтобы этот флаг был изменен только поставщиком libС++.

Ответ 2

libС++-реализация немного сложна, я проигнорирую ее альтернативный дизайн и предположим маленький конечный компьютер:

template <...>
class basic_string {
/* many many things */

    struct __long
    {
        size_type __cap_;
        size_type __size_;
        pointer   __data_;
    };

    enum {__short_mask = 0x01};
    enum {__long_mask  = 0x1ul};

    enum {__min_cap = (sizeof(__long) - 1)/sizeof(value_type) > 2 ?
                      (sizeof(__long) - 1)/sizeof(value_type) : 2};

    struct __short
    {
        union
        {
            unsigned char __size_;
            value_type __lx;
        };
        value_type __data_[__min_cap];
    };

    union __ulx{__long __lx; __short __lxx;};

    enum {__n_words = sizeof(__ulx) / sizeof(size_type)};

    struct __raw
    {
        size_type __words[__n_words];
    };

    struct __rep
    {
        union
        {
            __long  __l;
            __short __s;
            __raw   __r;
        };
    };

    __compressed_pair<__rep, allocator_type> __r_;
}; // basic_string

Примечание. __compressed_pair - это, по существу, пара, оптимизированная для Пустой базовой оптимизации, ака template <T1, T2> struct __compressed_pair: T1, T2 {};; для всех целей и целей вы можете считать это регулярной парой. Его важность возникает только потому, что std::allocator является апатридом и, таким образом, пуст.

Хорошо, это довольно сырой, поэтому пусть проверяет механики! Внутри многие функции вызовут __get_pointer(), который сам вызывает __is_long, чтобы определить, использует ли строка представление __long или __short:

bool __is_long() const _NOEXCEPT
    { return bool(__r_.first().__s.__size_ & __short_mask); }

// __r_.first() -> __rep const&
//     .__s     -> __short const&
//     .__size_ -> unsigned char

Честно говоря, я не уверен, что это Standard С++ (я знаю начальное положение подпоследовательности в union, но не знаю, как он соединяется с анонимным объединением и сглаживанием вместе), но стандартная библиотека разрешена чтобы в любом случае воспользоваться определением, определяемым реализацией.