Каждый раз, когда я упоминаю о низкой производительности iostreams стандартной библиотеки C ++, меня встречает волна недоверия. Тем не менее, у меня есть результаты профилировщика, показывающие большое количество времени, проведенного в коде библиотеки iostream (полная оптимизация компилятора), и переключение с iostreams на специфичные для ОС API-интерфейсы ввода-вывода и настраиваемое управление буфером дает улучшение порядка.
Какую дополнительную работу выполняет стандартная библиотека C ++, требуется ли она по стандарту и полезна ли она на практике? Или некоторые компиляторы предоставляют реализации iostreams, которые конкурируют с ручным управлением буфером?
Ориентиры
Чтобы начать работу, я написал несколько коротких программ для внутренней буферизации iostreams:
- положить двоичные данные в
ostringstream
http://ideone.com/2PPYw - размещение двоичных данных в
char[]
буфере http://ideone.com/Ni5ct - положить двоичные данные в
vector<char>
использованиеback_inserter
http://ideone.com/Mj2Fi - NEW :
vector<char>
простой итератор http://ideone.com/9iitv - NEW : размещение двоичных данных непосредственно в
stringbuf
http://ideone.com/qc9QA - НОВИНКА :
vector<char>
простой итератор и проверка границ http://ideone.com/YyrKy
Обратите внимание , что ostringstream
и stringbuf
версии работать меньше итераций , потому что они намного медленнее.
На ideone, то ostringstream
есть примерно в 3 раза медленнее , чем std:copy
+ back_inserter
+ std::vector
, и примерно в 15 раз медленнее , чем memcpy
в сырьевой буфер. Это похоже на профилирование до и после, когда я переключил свое реальное приложение на пользовательскую буферизацию.
Все это буферы в памяти, поэтому медлительность iostreams не может быть обвинена в медленном вводе-выводе диска, слишком большом сбрасывании, синхронизации с stdio или любых других вещах, которые люди используют, чтобы оправдать наблюдаемую медлительность стандартной библиотеки C ++ iostream.
Было бы неплохо увидеть тесты для других систем и прокомментировать то, что делают обычные реализации (такие как libc ++ gcc, Visual C ++, Intel C ++) и сколько накладных расходов предусмотрено стандартом.
Обоснование этого теста
Многие люди правильно отметили, что iostreams чаще используются для форматированного вывода. Однако они также являются единственным современным API, предоставляемым стандартом C ++ для доступа к двоичным файлам. Но настоящая причина для выполнения тестов производительности внутренней буферизации заключается в типичном форматированном вводе / выводе: если iostreams не может поддерживать контроллер диска с необработанными данными, как они могут поддерживать, когда они также отвечают за форматирование?
Контрольные сроки
Все это на итерацию внешнего k
цикла ( ).
На ideone (gcc-4.3.4, неизвестная ОС и оборудование):
ostringstream
: 53 миллисекундыstringbuf
: 27 мсvector<char>
иback_inserter
: 17,6 мсvector<char>
с обычным итератором: 10,6 мсvector<char>
проверка итератора и границ: 11,4 мсchar[]
: 3,7 мс
На моем ноутбуке (Visual C ++ 2010 x86, cl /Ox /EHsc
Windows 7 Ultimate, 64-разрядная, Intel Core i7, 8 ГБ ОЗУ):
ostringstream
: 73,4 миллисекунды, 71,6 мсstringbuf
: 21,7 мс, 21,3 мсvector<char>
иback_inserter
: 34,6 мс, 34,4 мсvector<char>
с обычным итератором: 1,10 мс, 1,04 мсvector<char>
проверка итератора и границ: 1,11 мс, 0,87 мс, 1,12 мс, 0,89 мс, 1,02 мс, 1,14 мсchar[]
: 1,48 мс, 1,57 мс
Visual C ++ 2010 x86, с профилем Guided Optimization cl /Ox /EHsc /GL /c
, link /ltcg:pgi
, бег, link /ltcg:pgo
, меры:
ostringstream
: 61,2 мс, 60,5 мсvector<char>
с обычным итератором: 1,04 мс, 1,03 мс
Тот же ноутбук, та же ОС, используя Cygwin GCC 4.3.4 g++ -O3
:
ostringstream
: 62,7 мс, 60,5 мсstringbuf
: 44,4 мс, 44,5 мсvector<char>
иback_inserter
: 13,5 мс, 13,6 мсvector<char>
с обычным итератором: 4,1 мс, 3,9 мсvector<char>
проверка итератора и границ: 4,0 мс, 4,0 мсchar[]
: 3,57 мс, 3,75 мс
Тот же ноутбук, Visual C ++ 2008 SP1, cl /Ox /EHsc
:
ostringstream
: 88,7 мс, 87,6 мсstringbuf
: 23,3 мс, 23,4 мсvector<char>
иback_inserter
: 26,1 мс, 24,5 мсvector<char>
с обычным итератором: 3,13 мс, 2,48 мсvector<char>
проверка итератора и границ: 2,97 мс, 2,53 мсchar[]
: 1,52 мс, 1,25 мс
Тот же ноутбук, 64-битный компилятор Visual C ++ 2010:
ostringstream
: 48,6 мс, 45,0 мсstringbuf
: 16,2 мс, 16,0 мсvector<char>
иback_inserter
: 26,3 мс, 26,5 мсvector<char>
с обычным итератором: 0,87 мс, 0,89 мсvector<char>
проверка итератора и границ: 0,99 мс, 0,99 мсchar[]
: 1,25 мс, 1,24 мс
РЕДАКТИРОВАТЬ: Выполнить все дважды, чтобы увидеть, насколько последовательными были результаты. Довольно последовательное ИМО.
ПРИМЕЧАНИЕ. На моем ноутбуке, поскольку я могу сэкономить больше процессорного времени, чем позволяет ideone, я установил число итераций равным 1000 для всех методов. Это означает, что ostringstream
и vector
перераспределение, которое происходит только на первом проходе, должно мало влиять на конечные результаты.
РЕДАКТИРОВАТЬ: Упс, обнаружил ошибку в vector
-with-обычно-итераторе, итератор не был продвинут, и поэтому было слишком много попаданий в кэш. Мне было интересно, как это vector<char>
было лучше char[]
. Это не имело большого значения, но vector<char>
все же быстрее, чем char[]
под VC ++ 2010.
Выводы
Буферизация выходных потоков требует трех шагов каждый раз, когда добавляются данные:
- Убедитесь, что входящий блок соответствует доступному буферному пространству.
- Скопируйте входящий блок.
- Обновите указатель конца данных.
Последний фрагмент кода, который я опубликовал, « vector<char>
простой итератор плюс проверка границ», не только делает это, но также выделяет дополнительное пространство и перемещает существующие данные, когда входящий блок не подходит. Как отметил Клиффорд, буферизация в классе файлового ввода-вывода не должна была бы этого делать, она просто очищает текущий буфер и использует его повторно. Так что это должна быть верхняя граница стоимости буферизации вывода. И это именно то, что нужно для создания рабочего буфера в памяти.
Так почему же в stringbuf
2,5 раза медленнее на идеоне и как минимум в 10 раз медленнее, когда я его тестирую? Он не используется полиморфно в этом простом микропроцессоре, поэтому это не объясняется.
источник
std::ostringstream
он недостаточно умен, чтобы экспоненциально увеличивать размер буфера, как этоstd::vector
происходит, это (A) глупо и (B) то, о чем должны думать люди, думающие о производительности ввода-вывода. В любом случае, буфер используется повторно, он не перераспределяется каждый раз. Иstd::vector
также использует динамически растущий буфер. Я пытаюсь быть честным здесь.ostringstream
и хотите максимально возможную производительность, то вам следует перейти прямо к этомуstringbuf
. Предполагается, чтоostream
классы связывают воедино функциональность форматирования с учетом локали с гибким выбором буфера (файл, строка и т. Д.)rdbuf()
И его интерфейс виртуальной функции. Если вы не выполняете никакого форматирования, тогда этот дополнительный уровень косвенности будет выглядеть пропорционально дороже по сравнению с другими подходами.ofstream
кfprintf
при выводе информации регистрации, включающей удвоения. MSVC 2008 на WinXPsp3. Iostreams это просто собака медленно.Ответы:
Не отвечая конкретно на ваш вопрос, а на заголовок: в Техническом отчете о производительности C ++ за 2006 год есть интересный раздел о IOStreams (с.68). Наиболее актуальным для вашего вопроса является раздел 6.1.2 («Скорость выполнения»):
Поскольку отчет был написан в 2006 году, можно было бы надеяться, что многие рекомендации будут включены в существующие компиляторы, но, возможно, это не так.
Как вы упомянули, фасеты могут не отображаться
write()
(но я бы не стал это принимать вслепую). Так что же особенность? Запуск GProf для вашегоostringstream
кода, скомпилированного с помощью GCC, дает следующую разбивку:std::basic_streambuf<char>::xsputn(char const*, int)
std::ostream::write(char const*, int)
main
std::ostream::sentry::sentry(std::ostream&)
std::string::_M_replace_safe(unsigned int, unsigned int, char const*, unsigned int)
std::basic_ostringstream<char>::basic_ostringstream(std::_Ios_Openmode)
std::fpos<int>::fpos(long long)
Таким образом, большая часть времени затрачивается на то
xsputn
, что в конечном итоге требуетstd::copy()
после множества проверок и обновления позиций курсора и буферов (посмотритеc++\bits\streambuf.tcc
детали).Я считаю, что вы сосредоточились на худшем случае. Вся выполняемая проверка будет составлять небольшую часть всей выполненной работы, если вы работаете с достаточно большими порциями данных. Но ваш код перемещает данные по четыре байта за раз и каждый раз несет все дополнительные расходы. Ясно, что в реальной жизни этого избежать не стоит - подумайте о том, насколько незначительным был бы штраф, если бы
write
он вызывался для массива с 1-м целым числом, а не с 1-м разом с одним целым числом. И в реальной жизни можно было бы по достоинству оценить важные функции IOStreams, а именно его безопасный для памяти и безопасный для типов дизайн. Такие преимущества имеют свою цену, и вы написали тест, в котором эти затраты влияют на время выполнения.источник
ostream::write()
.sizeof i
, но все компиляторы, с которыми я тестирую, имеют 4 байтаint
). И это не кажется мне таким уж нереальным, как вы думаете, какой размер блока передается при каждом вызовеxsputn
в типичном кодеstream << "VAR: " << var.x << ", " << var.y << endl;
.xsputn
пять раз, вполне может быть внутри цикла, который записывает файл длиной 10 миллионов строк. Передача данных в iostreams большими порциями - намного менее реальный сценарий, чем мой тестовый код. Почему я должен записывать в буферный поток с минимальным количеством вызовов? Если я должен сделать свою собственную буферизацию, какой смысл iostreams в любом случае? А с двоичными данными у меня есть возможность буферизовать их самостоятельно, когда записываешь миллионы чисел в текстовый файл, массового варианта просто не существует, я ДОЛЖЕН вызыватьoperator <<
для каждого.Я довольно разочарован в пользователях Visual Studio, которые, скорее всего, поделились этим:
ostream
, тоsentry
объект (который требуется стандарт) входит в критическую секцию , защищающуюstreambuf
(который не требуется). Это не является необязательным, поэтому вы платите за синхронизацию потоков даже для локального потока, используемого одним потоком, который не нуждается в синхронизации.Это очень больно код, который используется
ostringstream
для форматирования сообщений. Прямое использованиеstringbuf
исключает использованиеsentry
, но отформатированные операторы вставки не могут работать напрямую сstreambuf
s. В Visual C ++ 2010 критический раздел замедляетсяostringstream::write
в три раза по сравнению с базовымstringbuf::sputn
вызовом.Глядя на данные профилировщика beldaz на newlib , становится ясно, что gcc
sentry
не делает ничего такого сумасшедшего.ostringstream::write
под gcc занимает всего около 50% больше, чем самstringbuf::sputn
, ноstringbuf
сам по себе намного медленнее, чем под VC ++. И то, и другое по-прежнему весьма неблагоприятно для использованияvector<char>
буферизации ввода / вывода, хотя и не с той же разницей, что и в VC ++.источник
sentry
... «Класс sentry определяет класс, который отвечает за выполнение операций префикса и суффикса исключительной ситуации ». и примечание «Конструктор и деструктор также могут выполнять дополнительные зависящие от реализации операции». Из принципа C ++ «ты не платишь за то, что не используешь» можно предположить, что комитет C ++ никогда не утвердит такое расточительное требование. Но не стесняйтесь задавать вопрос о безопасности нитей iostream.Проблема, которую вы видите, связана с каждым вызовом метода write (). Каждый добавляемый вами уровень абстракции (char [] -> vector -> string -> ostringstream) добавляет еще несколько вызовов / возвратов функций и другие вспомогательные функции, которые, если вы вызываете это миллион раз, складываются.
Я изменил два примера на ideone, чтобы писать по десять целых за раз. Время остринстрима увеличилось с 53 до 6 мс (почти 10-кратное улучшение), в то время как цикл char улучшился (с 3,7 до 1,5) - полезно, но только в два раза.
Если вы беспокоитесь о производительности, вам нужно выбрать правильный инструмент для работы. ostringstream полезен и гибок, но есть штраф за использование его так, как вы пытаетесь. char [] сложнее, но прирост производительности может быть велик (помните, что gcc, вероятно, также встроит memcpys для вас).
Короче говоря, ostringstream не сломан, но чем ближе вы к металлу, тем быстрее будет работать ваш код. Ассемблер все еще имеет преимущества для некоторых людей.
источник
ostringstream::write()
нужно сделать, чтоvector::push_back()
нет? Во всяком случае, это должно быть быстрее, поскольку он передает блок вместо четырех отдельных элементов. Еслиostringstream
это медленнее, чемstd::vector
без предоставления каких-либо дополнительных функций, то да, я бы назвал это сломанным.stringbuf
напрямую не приведет к удалению всех вызовов функций, посколькуstringbuf
открытый интерфейс состоит из открытых не виртуальных функций в базовом классе, которые затем отправляются защищенной виртуальной функции в производный класс.sputn
функция, которая вызывает виртуальный защищенныйxsputn
, будет встроенным. Даже еслиxsputn
он не встроен, компилятор может во время встраиванияsputn
определить точноеxsputn
необходимое переопределение и сгенерировать прямой вызов без прохождения через vtable.Чтобы повысить производительность, вы должны понимать, как работают используемые вами контейнеры. В вашем примере с массивом char [] массив требуемого размера выделяется заранее. В вашем примере с вектором и ostringstream вы заставляете объекты многократно выделять, перераспределять и, возможно, копировать данные много раз по мере роста объекта.
С std :: vector это легко разрешается путем инициализации размера вектора до окончательного размера, как вы делали массив char; вместо этого вы довольно несправедливо ограничиваете производительность, уменьшая размер до нуля! Это вряд ли справедливое сравнение.
Что касается острингстрима, то предварительное распределение пространства невозможно, я бы предположил, что это нецелесообразное использование. Этот класс имеет гораздо большую полезность, чем простой массив char, но если вам не нужна эта утилита, не используйте ее, потому что в любом случае вы заплатите накладные расходы. Вместо этого его следует использовать для того, для чего он хорош - форматирования данных в строку. C ++ предоставляет широкий спектр контейнеров, и ostringstram является одним из наименее подходящих для этой цели.
В случае вектора и ostringstream вы получаете защиту от переполнения буфера, вы не получаете этого с массивом символов, и эта защита не предоставляется бесплатно.
источник
ostringstream.str.reserve(4000000)
и это не имело никакого значения.ostringstream
, вы могли бы «зарезервировать», передавая фиктивную строку, то есть: сostringstream str(string(1000000 * sizeof(int), '\0'));
помощьюvector
,resize
не освобождает пространство, оно расширяется, только если это необходимо.vector[]
по умолчанию оператор НЕ проверяется на наличие ошибок границ.vector.at()
однако.vector<T>::resize(0)
обычно не перераспределяет памятьoperator[]
, ноpush_back()
(в порядкеback_inserter
), что определенно проверяет переполнение. Добавлена другая версия, которая не используетсяpush_back
.