У нас и так под сотню потоков. Двигаясь по этому пути остается только изолировать каждую внешнюю библиотеку в отдельном потоке, но это весьма непростой вариант. Мне кажется, что это некорректное поведение библиотеки «вызвать» и не вернуть обратно. Правильный путь — найти, какая библиотека «гадит» и избавиться от нее (заменить).
Спасибо. Это, действительно помогло! Правда непонятно, как нам это знание теперь использовать:) У нас достаточно большой проект, использующий целый ряд внешних библиотек, в т.ч. кодеков (на них и грешим). Мы сами явно _controlfp не вызываем, а значит это делает кто-то. Непонятно, в какой момент времени нам делать вызов _controlfp(_PC_64, _MCW_PC), чтобы не слишком рано и не слишком поздно:)
Система реализована на базе Qt, поэтому для работы с файлами используем QFile. Открывается файл просто с параметром QIODevice::ReadWrite. Тормоза проявляются даже когда все операции чтения сконцентрированы в пределах первых 100Мб файла. Обычный режим — примерно 10 позиций, в которые данные пишутся и примерно столько же, откуда читаем. Из разных потоков.
Уважаемый, который минусанул вопрос и карму, я уверен, Вы знаете правильный ответ на мой возможно дилетантский вопрос;) Пожалуйста, найдите время и силы просветить нас! Обещаю, что я и все сотрудники нашей компании Вас за это заплюсуют!:)
Вариант работы с разделом жесткого диска напрямую реализован нами и в винде. Но заказчик упорно хочет в бюджетной версии системы создавать файл и работать с ним. Это комплексы, конечно, есть файл и его можно потрогать:) а нам приходится удовлетворять:).
Винда совсем по другому работает.
Согласен. Но, простите, есть документированные API по работе с файлами. Мы не делаем ничего криминального и не творим никакого black magic-a, поэтому совершенно резонно возникает вопрос «а какого ....?»:)
Вопрос действительно больше похож на «статью»:). Вопрос не о том, как нужно что-то хранить, поэтому и не стал вдаваться в детали, что именно мы храним. Файл — это состоявшееся проектное решение и хочется понять, почему наблюдается такое поведение.
От хранения потоков в файлах мы ушли много лет назад, т.к. поняли (в Linux версии), что наличие файловой системы нам не нужно и мы можем разместить данные на разделе, оперируя с ним как с блочным устройством, максимально эффективно именно для наших задач. Использование большого файла в Windows — это попытка портировать уже имеющееся решение под слегка изменившиеся внешние условия.
Повторяли чтение сотни раз — ускорения НЕ происходит, следовательно гипотеза с кэшем, к сожалению не верна.
Кэш явно задействовался, когда мы работали с обычными (non-sparse) файлами, мы видели скачек потребления системной памяти (не памяти нашего процесса!) и этот пик иногда приводил к обрушению программы. Переход на sparse файлы эту проблему вылечил, заменив ее на другую.
Да, это именно sparse file. При работе со sparse файлами никаких аномалий с загрузкой процессора или излишними потреблениями памяти мы не замечали. Только тормоза и только после перезапуска программы. Компрессию NCFS тоже пробовали выключать.
