Есть код:
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;}
}

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

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

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

>>SetPriorityClass - LOW не помогает...
В который раз повторяю) Приоритет != размер кванта. Если в системе нет других готовых к выполнению потоков того же или высшего приоритета, то все процессорное время будет отнимать твой поток.

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

не консоль =\

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

Great пишет:
>>SetPriorityClass - LOW не помогает...
В который раз повторяю) Приоритет != размер кванта. Если в системе нет других готовых к выполнению потоков того же или высшего приоритета, то все процессорное время будет отнимать твой поток.
Стало быть как...?

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

Руками ограничивай работу потока, который выполняет тяжелую работу.

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

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

просто замути слип где-нибудь sleep(1) например

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

Если файл надо прочитать один раз с начала до конца, маппинг совершенно не нужен. Тем более что если файл больше, чем размер свободного адресного пространства, то маппинг всего файла не сработает. Лучше юзать FILE_FLAG_NO_BUFFERING и обычный ReadFile. Для ускорения можно разнести чтение буфера и обработку данных в разные потоки (см. FILE_FLAG_OVERLAPPED и параметр lpOverlapped).

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

2reverser
А вот про это можно поподробнее? ReadFile всё равно порциями читать или как-то иначе? В справке как-то расплывчато: доступ к файлу должен начинаться со смещений в файле, кратных размеру сектора тома; доступ к файлу должен выполняться для ввода/ вывода числа байтов, кратных размеру сектора тома; адреса буферов для операций чтения и записи должны быть выровнены по границам адресов памяти, кратных размеру сектора тома.
Как я понял куча ограничений, а читать всё равно порционно?

PS И почему нельзя тупо "просмотреть байтики файла" прямо с диска, средствами системы прыгая между фрагментами, ничего не кешируя в память...

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

Freecod пишет:
PS И почему нельзя тупо "просмотреть байтики файла" прямо с диска, средствами системы прыгая между фрагментами, ничего не кешируя в память...
потому что процессор соединен с оперативной памятью, а не жеским диском

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

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

>>ReadFile всё равно порциями читать или как-то иначе? В справке как-то расплывчато: доступ к файлу должен начинаться со смещений в файле, кратных размеру сектора тома; доступ к файлу должен выполняться для ввода/ вывода числа байтов, кратных размеру сектора тома; адреса буферов для операций чтения и записи должны быть выровнены по границам адресов памяти, кратных размеру сектора тома.

для FILE_FLAG_NO_BUFFERING? я про него чето забыл уже надо посмотреть

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

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

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

Вообщем старым добрым ReadFile всё сделал.
while (allpos < dwFileSize) // allpos - смещение по файлу
{
if (dwFileSize - allpos > SizeReadBuffer) // SizeReadBuffer - размер кучи
{
SetFilePointer(hFile,allpos,0,0);
sizebuf = SizeReadBuffer;
ReadFile(hFile, pMem, sizebuf, &dwBytes, 0);
r = ParseMem(s, sizebuf, &pos, FALSE);
}
else {
SetFilePointer(hFile,allpos,0,0);
sizebuf = dwFileSize - allpos;
ReadFile(hFile, pMem, sizebuf, &dwBytes, 0);
r = ParseMem(s, sizebuf, &pos, TRUE);
}
allpos = allpos+pos; // если встречены нужные данные, но буфер кончается
}

Надеюсь работать будет достаточно шустро...

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

Кстати, а в чём разница между VirtualAlloc и CreateHeap? ЧТо приминительно к этой задаче лучше?

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

Такая же, как между яблоком и камазом. Мало общего.
Может ты имел в виду VirtualAlloc & HeapAlloc?
Тогда отвечаю:
Операционная система позволяет выделить память постранично (страница=4кб) из-за особенностей архитектуры IA-32. Это делает функция VirtualAlloc. Ей передаешь размер и она выделяет нужное число страниц.
Но часто требуется выделять меньшие объемы - сотни байт. Для этого существует куча - менеджер кучи выделяет себе несколько страниц памяти и размечает эту область на блоки (свободные/занятые). При запросе HeapAlloc менеджер кучи ищет свободный блок и возвращает указатель на него (помечая как занятый, конечно).
А вызов VirtualAlloc с размером в сотню байт все равно закончится выделением одной страницы (4кб)

Что лучше? Если тебе нужно выделять память размером до 4кб то лучше использовать кучу. Если больше - выделять сразу страницами

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

VirtualAlloc также отрабатывает быстрее и выделяет память, выровненную по 64Kb (по крайней мере "обычно" ). Такой выровненный буфер обычно лучше для ввода-вывода (на WinCE так вообще для низкоуровнего IO единственно возможный ).

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

А windows посылает сообщения при подключении новых устройств? Мне нужно "подхватывать" устройства (накопители естественно) в реальном времени. Пока кручу цикл GetLogicalDriveStrings(150, DrvList); GetDriveType(&DrvList[i]); , но тут сразу куча неудобств. Если диск уже добавлен (флешка например), её отключают, а потом подкл. другую - идём лесом =\ Нет способа отловить момент подключения нового диска и желательно его букву...

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

Посмотри, как сервис "Обнаружение оболочки оборудования" работает.

-----
invoke OpenFire

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

Попробуй мониторить WM_SETTINGCHANGE.

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

Хм. А можно мониторить сообщения без окна? Например у меня неконсольное приложение, но без окон. Хотелось бы отлавливать завершение системы.

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