Здравствуйте, Cyberax, Вы писали:
C>Эмуляция файла — это очень полезный строительный блок.
Для строительства чего?
C>Короче говоря, чрезвычайно полезная вещь.
Полезность любой вещи определяется в первую очередь массовостью и частотой ее применения. Какая часть программ под Linux использует эти средства эмуляции файлов, и для чего именно?
Здравствуйте, Евгений Музыченко, Вы писали:
C>>Эмуляция файла — это очень полезный строительный блок. ЕМ>Для строительства чего?
Приложений.
C>>Короче говоря, чрезвычайно полезная вещь. ЕМ>Полезность любой вещи определяется в первую очередь массовостью и частотой ее применения. Какая часть программ под Linux использует эти средства эмуляции файлов, и для чего именно?
Композиторы видео используют их для передачи кадров, например. В Андроиде повсеместно используется для избежания копирования памяти (только ashmem, а не memfd).
Здравствуйте, Cyberax, Вы писали:
C>>>Эмуляция файла — это очень полезный строительный блок. ЕМ>>Для строительства чего? C>Приложений.
Мне при строительстве приложений ни разу не требовалось эмуляции файлов. Что я все эти годы делал не так?
C>Композиторы видео используют их для передачи кадров, например. В Андроиде повсеместно используется для избежания копирования памяти (только ashmem, а не memfd).
Зачем для этого ставить концепцию с ног на голову и эмулировать файл? То, что Вы упомянули, всю жизнь называлось "потоковой передачей данных". Поток может быть связан и с реальным файлом, но представлять любой поток в виде этакого "виртуального файла" — явное извращение, ибо поток — это в первую очередь именно поток данных, который вовсе не обязан быть связан с ФС хоть прямо, хоть косвенно.
S>мы в секунду создаем несколько тыс файлов и после обработки удаляем их, хотелось соптимизировать процесс S>я смог решить задачу подменой функций
В таком случае проще всего создать диск в памяти (желательно с fat32, она быстрее) и работать с "несколько тыс файлов" в нём. Или программа работает не у вас, а. у пользователей? Тогда создавать диск программно. Либо FUSE (есть реализации под Windows). Либо перехват функций работы с файлами (их не так много).
R>P.S. Не очень понимаю, почему файловая система может тормозить при создании и удалении файлов. Т.е. IMHO, для задачи ТС FS должна работать достаточно быстро (файлы в памяти, кончено, быстрее, но и обычная FS должна работать достаточно быстро без хаков, вопрос, почему это не так...). Журнал, насколько я понимаю, не сбрасывается на диск до возвращения из системного вызова "создать файл" (это же не база данных с транзакциями), т.е. по сути все операции работы с FS в ядре должны происходить в памяти. Записи на диск, если и будут (файл создали, через секунду удалили, затем на том же месте создали новый), произойдут в фоне, т.е. тормозить не должны. Остаются переключения контекста (в ядро и обратно), которые в Linux ~1мкс, работа с файловым кешем (в памяти) и пометка страниц, которые нужно в фоне сбросить на диск (в Linux процесс сброса запускается раз в 5 секунд, если памяти достаточно). Возможно, это опять же это особенность FS в Windows...
в секунду создаються и сохраняються на диск N количество файлов
те создали, записали, закрыли, передали путь в балансер задач
если считать только записываемых данные без системных областей диска получаеться несколько G в секунду
а сейчас все в RAM работает
Здравствуйте, sergey2b, Вы писали:
S>в секунду создаються и сохраняються на диск N количество файлов S>те создали, записали, закрыли, передали путь в балансер задач S>если считать только записываемых данные без системных областей диска получаеться несколько G в секунду S>а сейчас все в RAM работает
Такое впечатление, что одно кривое решение Вы пытаетесь спасти еще более кривым. Надеюсь, это хоть внутренний продукт, не релизный?
Здравствуйте, reversecode, Вы писали:
ЕМ>>это хоть внутренний продукт, не релизный?
R>сомнительно что это продукт R>больше похоже на сервис аля нетфликс
Это и есть "внутренний продукт". Если крутится сугубо на их аппаратуре — по барабану, как там что реализовано. А вот если такое выпускается в релиз, и ставится у потребителей — обильные маты гарантированы.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, reversecode, Вы писали:
ЕМ>>>это хоть внутренний продукт, не релизный?
R>>сомнительно что это продукт R>>больше похоже на сервис аля нетфликс
ЕМ>Это и есть "внутренний продукт". Если крутится сугубо на их аппаратуре — по барабану, как там что реализовано. А вот если такое выпускается в релиз, и ставится у потребителей — обильные маты гарантированы.
типа внутреннему продукту будет наплевать как это нужно будет поддерживать?
не, думаю бизнесу виднее
если он нанимает таких сергеев
значит бизнес согласен на кривопопые решение — лишь бы как нибудь работало
так кстати большинство контор делает и для паблик продукта
Здравствуйте, reversecode, Вы писали:
R>типа внутреннему продукту будет наплевать как это нужно будет поддерживать?
По крайней мере, сор не выносится за пределы организации. В конце концов, кто и когда интересовался, на чем и как написан тот или иной сервис, если со стороны пользователя этого никак не видно?
ЕМ>По крайней мере, сор не выносится за пределы организации. В конце концов, кто и когда интересовался, на чем и как написан тот или иной сервис, если со стороны пользователя этого никак не видно?
разрабам которые ходят из конторы в контору и рассказывают стоит ли куда соваться или там очередное решение на cоплях от очередных прогОмистов сергеев
которых уже уволили
Здравствуйте, sergey2b, Вы писали: S>Подскажите пожалуйста есть ли функции Win API или библиотека позволяюшая эмулировать файл в памяти S>при этом надо чтобы файловый HANDLE был валидны S>конечная цель сделать так что бы чужая библиотека работала с файлом в RAM а не на диске Temporary file
If you are WRITING the file in your application you can try creating with:
FILE_ATTRIBUTE_TEMPORARY and FILE_FLAG_DELETE_ON_CLOSE
Файл всё равно физически создастся на диске, а при превышении размера файлового кэша ещё и зафлюшится. Но система будет стараться не флюшить до последнего.
the FILE_ATTRIBUTE_TEMPORARY attribute does tell the system to hold as much as possible in the system cache without writing and therefore may be of concern for certain applications.
M>Файл всё равно физически создастся на диске, а при превышении размера файлового кэша ещё и зафлюшится. Но система будет стараться не флюшить до последнего. M>
M>the FILE_ATTRIBUTE_TEMPORARY attribute does tell the system to hold as much as possible in the system cache without writing and therefore may be of concern for certain applications.
Это неплохо, ибо Вам же нужно не только голое быстродействие, но ещё и надёжность.
Если у Вас с файлами в памяти закончится эта память, то будет обидно за потерянные данные.
А здесь эти данные просто уйдут на диск.
