Мы многократно записываем (много раз по 1000 раз) в один большой архивный файл, исправляя его различные части. После каждой записи мы вызывали FileFlushBuffer (), но обнаружили, что это очень, очень медленно. Если мы будем ждать и вызывать его только время от времени (скажем, каждые 32 файла), дела пойдут лучше, но я не думаю, что это правильный способ сделать это.
Есть ли способ вообще не очищать буфер, пока мы не закончим наш последний патч? Если мы полностью уберем вызов, close () обработает сброс, но сам по себе он становится огромным узким местом. В противном случае, если он не заблокирует другие наши потоки при запуске, это сделает его менее раздражающим, так как мы не будем делать IO чтения IO для этого файла вне записи. Такое ощущение, что дисковая система действительно мешает.
Подробнее:
Целевой файл в настоящее время составляет 16 гигабайт, но постоянно меняется (обычно в сторону увеличения). Мы случайным образом проверяем файл в обновлениях, и он достаточно большой, чтобы мы не могли кэшировать весь файл. С точки зрения фрагментации, кто знает. Это большая база данных ресурсов, которая часто обновляется, поэтому вполне вероятно. Не уверен, как сделать это не фрагмент. Опять же, открыты для любых предложений.