Есть код:
HANDLE hFile, hfMap, pMap;

hFile = CreateFile(name,GENERIC_READ || GENERIC_WRITE,FILE_SHARE_READ,0,OPEN_EXISTING,0,0);
if (hFile == INVALID_HANDLE_VALUE) {return 0;}

dwFileSize = GetFileSize(hFile,0);
if (dwFileSize <= 16 || dwFileSize >= 500000000) {return 0;}

hfMap = CreateFileMapping(hFile, NULL, PAGE_READONLY, 0, 0, NULL);
if (hfMap == NULL) {return 0;}

pMap = MapViewOfFile(hfMap,FILE_MAP_READ,0,0,0);
if (pMap == NULL) {return 0;}

CHAR *s = (CHAR*)((DWORD)(pMap));

while (s[Cur] < '0' || s[Cur] > '9')
{
Cur++;
if (Cur >= dwFileSize) {return 1;}
}

Изначально, после маппинга, расход опер. памяти не изменился. Но как только начинаю проверять содержимое файла, расход оперативки растёт вплоть до размера файла! Можно это забороть?

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

| Сообщение посчитали полезным:

ну тут вам самому надо решить, либо жрать оперативу и работать в файлмепингом ( покускам примером ), либо забить на быстродействие и читать с файла

| Сообщение посчитали полезным:

А если попробовать указать в CreateFileMapping параметр dwMaximumSizeLow = 1024 * 1024 * 1024, то разве размер "окна" не будет ограничен мегабайтом ?

| Сообщение посчитали полезным:

sss пишет:
А если попробовать указать dwMaximumSizeLow = 1024 * 1024 * 1024, то разве размер "окна" не будет ограничен мегабайтом ?
CrFileMapp. в случае hfMap = CreateFileMapping(hFile, NULL, PAGE_READONLY, 0, 1024 * 1024 * 1024, NULL); возвращает NULL...

| Сообщение посчитали полезным:

Циклический буфер пока никто не отменял.
Делается обычный буфер в памяти, размером 2х-3х больше "искомых данных в файле".
Читается изначально читается весь буфер, поиск идет до "конца первого куска" с безопасным оверлапом.
Потом память мувится и один из кусков замещается новым из файла. Накладные расходы на чтение с диска значительно выше, чем на грамотно написанный MoveMemory

| Сообщение посчитали полезным:

Да, и еще: CreateFileMapping не отменяет подъем данных с диска и тем самым - те же накладные расходы на чтение.
Все прелесть циклического буфера (особенно 3х) заключается в возможности выполнять операции полностью асинхронно: несколько Мб фала зачастую подымаются дольше, чем параллельно инфа обрабатывается .

Схема где-то такая:
изначально подымаются 2 куска из 3х (синхронно), третий сшедулится асинхронно (через "оверлапд"), обрабатываются первый кусок (залезая отчасти во второй), дожидаемся завершения асинхронного чтения, мовим буфер (перемещая 2,3 в 1,2), продолжаем обрабатывать 2й кусок (который стал первым) пердварительно зашедулив асинхронное чтение нового 3го куска. и т.д.
Просадка скорости может быть только на:
1) Если обработка данных выполняется медленнее чем чтение (тогда суммарная скорость получается скорость обработки+время на мов памяти)
2) Если чтение диска таки медленние (что бывает в 90% случаев) - тогда скорость диска + время на мов памяти.

Второе слагаемое незначительное по сравнении с первым и на athlon x64 3200 + и RAID0 2x составляет около 3-5% от общего времени (это тестилось).

| Сообщение посчитали полезным:

И не забудь, что читать надо данные по 64 кб,т.к. именно такой размер обеспечивает максимальную быстроту работы с файлами при чтении/записи. (в XP, про висту не знаю)

-----
Само плывет в pуки только то, что не тонет.

| Сообщение посчитали полезным:

кратно
Если речь идет именно о больших файлах, вряд ли 64x16 причитается быстрее, чем 1024x1.


А соптимайзить (если чтение таки медленнее обработки) на 3х буфере можно еще перемещзением 2->1 _перед_ завершением асинхронного чтения, потом уж 3->2

| Сообщение посчитали полезным:

а в общем, лучше размер буфера сделать переменной или задефайнить и погонять на практике, при каком будет лучше (с разными размерами входных файлов). логично предположить, что это будет 64кб+

| Сообщение посчитали полезным:

Как раз недавно проводил эксперимент по размеру буфера-скорости записи

Синхронная запись файла размером 20mb с изменением размера блока от 256b до 20mb:
buffer_size - 256 time is 141.249 ms
buffer_size - 512 time is 84.7206 ms
buffer_size - 1024 time is 54.3948 ms
buffer_size - 2048 time is 41.332 ms
buffer_size - 4096 time is 34.5539 ms
buffer_size - 8192 time is 28.0534 ms
buffer_size - 16384 time is 24.431 ms
buffer_size - 32768 time is 23.0809 ms
buffer_size - 65536 time is 23.378 ms
buffer_size - 131072 time is 22.1039 ms
buffer_size - 262144 time is 22.1926 ms
buffer_size - 524288 time is 142.334 ms
buffer_size - 1048576 time is 340.674 ms
buffer_size - 2097152 time is 332.983 ms
buffer_size - 4194304 time is 312.782 ms
buffer_size - 8388608 time is 378.822 ms
buffer_size - 16777216 time is 308.668 ms
buffer_size - 20971520 time is 225.883 ms

Чтение не тестил, но врядле картинка изменится.
ЗЫ: время не на запись блока, а на запись всех 20мбайт по кускам с такими буферами.

-----
Недостаточно только получить знания:надо найти им приложение

| Сообщение посчитали полезным:

Freecod пишет:
GENERIC_READ || GENERIC_WRITE
Путаете битовое и логическое

| Сообщение посчитали полезным:

Rascal пишет:

Как раз недавно проводил эксперимент по размеру буфера-скорости записи

Результат мягко говоря странный (256Kb<->512Kb). Что было запущено в процессе? Это один проход или "среднее"? Фрагментация ФС? Что за ФС?

| Сообщение посчитали полезным:

ashghost пишет:
Что было запущено в процессе?
? в каком процессе? Что запущено?

ashghost пишет:
Это один проход или "среднее"
Среднее. Проводил тесты с разными файлами на разных логических разделах разных размером. Это пороговое место везде подтверждалось. На флешке например такой результат:

Синхронная запись файла размером 2mb с изменением размера блока от 256b до 2mb на флеш:

buffer_size - 256 time is 8.46768 ms
buffer_size - 512 time is 24.1406 ms
buffer_size - 1024 time is 22.7433 ms
buffer_size - 2048 time is 15.1558 ms
buffer_size - 4096 time is 2634.57 ms
buffer_size - 8192 time is 1550.96 ms
buffer_size - 16384 time is 1023.72 ms
buffer_size - 32768 time is 747.101 ms
buffer_size - 65536 time is 668.474 ms
buffer_size - 131072 time is 539.104 ms
buffer_size - 262144 time is 959.713 ms
buffer_size - 524288 time is 902.685 ms
buffer_size - 1048576 time is 815.984 ms
buffer_size - 2097152 time is 453.228 ms

ashghost пишет:
Фрагментация ФС? Что за ФС?
Фрагментация врядл, ибо проводился эксперимент не раз. Создавался файл, замтем удалялся, опять создавался итп. Размер файла один. Раздел практически чист. ФС - ntfs. Для флешки соотв. Код вроде как в норме. Могу выложить.

-----
Недостаточно только получить знания:надо найти им приложение

| Сообщение посчитали полезным:

Вот собсно ехе с батником. чтоб узнать чо какой параметр значит - запускаем без батника.

c49e_22.05.2008_CRACKLAB.rU.tgz - Release.rar

-----
Недостаточно только получить знания:надо найти им приложение

| Сообщение посчитали полезным:

? в каком процессе? Что запущено?

Некорректно выразился: "во время тестирования".
К примеру антивирь мог файлы трогать (или сканить параллельно) и т.д.


buffer_size - 131072 time is 539.104 ms
buffer_size - 262144 time is 959.713 ms
buffer_size - 524288 time is 902.685 ms

Легче (таки не в 7 раз ); похоже на то, что нужно.


buffer_size - 2097152 time is 453.228 ms
а вот эта часть интересна. посему и рекомендовал "погонять".

Фрагментация врядл, ибо проводился эксперимент не раз. Создавался файл, замтем удалялся, опять создавался итп. Размер файла один. Раздел практически чист. ФС - ntfs.
ОК.

Для флешки соотв.
Флешки??


Код вроде как в норме. Могу выложить.
Если в коде простой цикл, смысла думаю нет.

| Сообщение посчитали полезным:

ashghost пишет:
buffer_size - 131072 time is 539.104 ms
buffer_size - 262144 time is 959.713 ms
buffer_size - 524288 time is 902.685 ms

Легче (таки не в 7 раз ); похоже на то, что нужно.

=)

Rascal пишет:
buffer_size - 2048 time is 15.1558 ms
buffer_size - 4096 time is 2634.57 ms
;)

[ADDED]
для сигейта 200гб скачок находится тут. это для 10мб файла. ваще чем больше файл, тем меньше влияет размер буфера на скорость. на моих винчах. в идеале если делать софт с ручной подкачкой данных - нада проводить в программе тест записи блоков, и использовать оттуда величину буфера.

buffer_size - 262144 time is 8.51633 ms
buffer_size - 524288 time is 329.003 ms
buffer_size - 10485760 time is 998.373 ms

-----
Недостаточно только получить знания:надо найти им приложение

| Сообщение посчитали полезным:

Ну интересно что после мэппинга опер. память не занимается сразу во весь размер файла, а только с "оборотами" while.
Если выбирать, то готов уступить скорость оптимизации памяти - так что что там с "окном" у CreateFileMapping? CreateFileMapping(hFile, NULL, PAGE_READONLY, 0, 1024, NULL); - следующие 1024 байта придыдущие не освобождают как я понял, выпадаем в исключение =(.
Циклический буфер прикручивать к готовому уже коду - куча проблем, мне бы спихнуть всё это на систему и встр. функции, для "себя" представляя это одной большой кучей байт...

| Сообщение посчитали полезным:

asmfan пишет:
Freecod пишет:
GENERIC_READ || GENERIC_WRITE
Путаете битовое и логическое
Епть, только сейчас заметил. Драл код из своего исходника на асме =)

| Сообщение посчитали полезным:

[...]

| Сообщение посчитали полезным:

>>Ну интересно что после мэппинга опер. память не занимается сразу во весь размер файла, а только с "оборотами" while.

На самом деле можешь не париться по этому поводу, в винде механизм управления памятью весьма гибкий.
Страницы считываются в оперативную память (отнимая свободную часть последней) по мере обращения, мало того, если другому процессу вдруг потребуется память и в системе будет мало свободных страниц, твои страницы нагло заберут - если они были модифицированы, их скинут на диск и отнимут в пользу другого процесса, в противном случае просто отнимут в пользу другого процесса.
Когда ты в следующий раз обратишься к ним, будет ошибка страницы и данные снова загрузят из файла в память. Так что никакого перерасхода памяти я не вижу - если памяти достаточно свободной, тогда страницы будут у тебя почти всегда, если мало - у тебя будут их периодически отнимать, но для тебя все равно все будет прозрачно. Так же, Windows периодически усекает рабочие наборы процессов (например бездействующий процесс практически не будет занимать ОЗУ в конце концов - большая часть выгружаемых страниц будет освобождена и переведена в список свободных. Если что - их снова прочитают из файла подкачки или проецируемого файла (зависит от их природы)).

| Сообщение посчитали полезным:

Мешает сам факт помещения большого объёма данных в память - начинает выгружать "неиспользуемые библиотеки", как следствие тормоза, итп.

| Сообщение посчитали полезным:

Freecod пишет:
Мешает сам факт помещения большого объёма данных в память - начинает выгружать "неиспользуемые библиотеки", как следствие тормоза, итп.

Не хочешь чтоб памяти много занималось, не юзай MapViewOfFile (данные подгружай и выгружай когда надо)

2 Great: сам бы лучше не написал =)

| Сообщение посчитали полезным:

>>2 Great: сам бы лучше не написал =)

в плане, не понял? ))

>> Мешает сам факт помещения большого объёма данных в память - начинает выгружать "неиспользуемые библиотеки", как следствие тормоза, итп.
а зачем ты проецируешь весь файл?
можно маппинг делать на весь файл (CreateFileMappingA/W), а виды делать по кусочкам (MapViewOfFile[Ex])

| Сообщение посчитали полезным:

Great пишет:
>>2 Great: сам бы лучше не написал =)

в плане, не понял? ))

хорошо написал, хвалю
_________________________________

можно что-то наподобие своего менеджера памяти замутить, но это фигня какая-то =)

| Сообщение посчитали полезным:

я даже не понял это сарказм или действительно похвала))
зы. у меня и статья на тему памяти есть.. на васме можно найти в top50 в первой десятке.

>> можно что-то наподобие своего менеджера памяти замутить, но это фигня какая-то =)
затрахаешься) хотя.. я щас пишу менеджер памяти для своей ОС, как раз маппинг реализовываю

| Сообщение посчитали полезным:

Great пишет:
я даже не понял это сарказм или действительно похвала))
это похвала

Great пишет:
затрахаешься) хотя.. я щас пишу менеджер памяти для своей ОС, как раз маппинг реализовываю
я говорю что фигня какая-то, но мона свой аналог маппинга замутить (и даже свой файл подкачки)

| Сообщение посчитали полезным:

Great пишет:
можно маппинг делать на весь файл (CreateFileMappingA/W), а виды делать по кусочкам (MapViewOfFile[Ex])
Т.е. поработали с этим "кусочком", потом снова MapViewOfFile, следующий кусочек, итп... Так? Или он сам будет окошко на кусочки двигать? :с надеждой: =)
Т.е. будет как тот же самый ReadFile по, скажем, метру в буфер какой-нибудь?

Ещё вопрос: программа должна искать невнапряг пользователю, даже когда простаивает не отъедать больше 3-5% процессора. SetPriorityClass - LOW не помогает...

| Сообщение посчитали полезным:

Freecod пишет:
даже когда простаивает не отъедать больше 3-5% процессора
програмить под виндой учись =)

Freecod пишет:
поработали с этим "кусочком", потом снова MapViewOfFile, следующий кусочек, итп...
тогда легче ReadFile юзать

| Сообщение посчитали полезным:

SL7549 пишет:
Freecod пишет:
даже когда простаивает не отъедать больше 3-5% процессора
програмить под виндой учись =)
И всё таки? Ждать? Этож извращение...

| Сообщение посчитали полезным:

какая хоть программа? консольная или оконная?

| Сообщение посчитали полезным: