Ускорить запись в файл в Windows, Как уменьшить потери времени на запись в файл Опции

[Igor87]

Есть задача: принимать данные от аппаратуры программой1 и через файл передавать их в программу2. Действие происходит в Windows XP.
При этом не устраивает скорость записи данных в файл. Передача осуществляется средствами WinAPI.
Есть ли более быстрые способы передачи данных?
Желательно минимальное изменение изменение кодов программ по причине того, что программу 1 и 2 делают разные люди.

[Deka]

Можно попробовать сделать виртуальный диск и именно там расположить файл. Это позволит не переделывать программы.

[Igor87]

Можно попробовать сделать виртуальный диск и именно там расположить файл. Это позволит не переделывать программы.

А как это можно сделать?

По поводу CreatePipe, я читал, что все механизмы межпроцессного взаимодействия основаны на файлах отображаемых на память. И в пределе могут достигать скорости этого метода. Так что я пока остановился на файлах отображаемых в память. Вроде задержки уменшились, но возникла проблема того, что весь файл надо держать в памяти, а он может заполняться данными около часа.Там объем приличный может набегать.
Я думал, что можно отображать часть файла, но похоже ошибся.
Вот только память выделяется как-то не прямо пропорционально.То есть я вроде отображаю здоровый файл, а прибавка занимаемой памяти процессором маленькая.То есть механизм состоит не в том, что файл целиком находится в оперативной памяти, правильно?

[Terrarium]

Вот только память выделяется как-то не прямо пропорционально.То есть я вроде отображаю здоровый файл, а прибавка занимаемой памяти процессором маленькая.То есть механизм состоит не в том, что файл целиком находится в оперативной памяти, правильно?

Для обмена данными с помощью общей памяти используются три функции:
CreateFile - собственно создаем начальный handle, который дублируем в другой программе,
CreateFileMapping - задаем, какого размера у нас будет общая память
MapViewOfFile - создаем "окно", в которое 1-й процесс пишет, 2-й - читает...

Поэтому, Вы можете создать большое общее пространство, и, открывая в нем "окна" небольшого размера для записи, записав, уведомлять считывающую программу о готовности очередного окна. Программа-считыватель открывает окно, читает, посылает уведомление пишущей, та закрывает окно, и оперативная память для данного окна освобождается. Поэтому реально выделенный объем будет равен ровно тому объему, который уже записан, но еще не прочитан. Далее, организуется запись "по кругу", когда вы по достижении конца файла начинаете писать в его начало. Если вы читаете быстрее, чем пишете, получится стабильная система.

Насчет страниц памяти тоже все верно, для современных интеловских процессоров размер страницы составляет 4 килобайта, на кратную величину и надо ориентироваться...

Использование каналов, на мой взгляд, для данной задачи несколько удобнее, потому что вам не нужно заботиться о синхронизации - для случая с потоком, скажем, 1 мегабайт/с это вполне подойдет (если, конечно, приемник успевает "переварить" этот поток с точки зрения вычислительной трудоемкости). Кроме того, для ОС Линукс такой подход вообще стандартен - перенаправить вывод одной программы на ввод другой - например, результат поиска файлов на поиск шаблона имени а потом на программу сортировки. При этом вся буферизация/синхронизация ложится на ОС, и все работает очень эффективно - самому написать без вдумчивого анализа и большого опыта написания многопоточных программ вряд ли получится...

Если же потоки горазбо больше - гигабитный Ethernet фильтровать, к примеру, то, как альтернативу, предлагаю рассмотреть возможность использования MPI - ru.wikipedia.org/wiki/MPI - он изначально создавался для больших вычислительных систем с интенсивным обменом данными между различными процессами/узлами кластеров.