Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Delphi Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3      [все]
 Файлы, отображаемые в память.  [new]
Ежов Дмитрий Сергеевич
Member

Откуда: Новокузнецк-Москва, Россия
Сообщений: 100
День добрый.
Есть ли в Дельфи компоненты, позволяющие работать с маппированными файлами.
Желательно, наследники TFileStream

?
12 ноя 20, 14:58    [22230794]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51775

Работа с такими файлами принципиально не укладывается в интерфейс TStream.

Posted via ActualForum NNTP Server 1.5

12 ноя 20, 15:03    [22230801]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
wadman
Member

Откуда: Санкт-Петербург
Сообщений: 26836
Мой гугл сразу выдал ссылку на https://torry.net/pages.php?id=228
12 ноя 20, 15:06    [22230805]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
_Vasilisk_
Member

Откуда: Украина, Харьков
Сообщений: 12319
Dimitry Sibiryakov
Работа с такими файлами принципиально не укладывается в интерфейс TStream.
Да ладно, TIBBlobStream укладывается, а MMF нет
12 ноя 20, 15:33    [22230831]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51775

_Vasilisk_
TIBBlobStream укладывается, а MMF нет

BLOB - поток данных неизвестного размера, последовательно читаемый кусками. MMF - кусок
данных заданного размера. Ничего общего.

Posted via ActualForum NNTP Server 1.5

12 ноя 20, 15:57    [22230853]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
alekcvp
Member

Откуда:
Сообщений: 2494
Dimitry Sibiryakov

Работа с такими файлами принципиально не укладывается в интерфейс TStream.

Серьёзно?..
Я в своё время пытался прикрутить TSteam к MMF ради эксперимента, но за ненадобностью не доделал.
Но ничего "принципиального" я там не вижу.
+
unit smMappedFile;

interface

uses
  System.SysUtils, System.Classes;

type
  TMappedFileStream = class(TStream)
  private
    FFileName: string;
    FHandle: THandle;       // file handle
    FMappedBase: Int64;     // mapping start position
    FMappedSize: NativeInt; // current size of mapping window
    FMapping: THandle;      // handle of file mapping
    FBufferSeek: NativeInt; // file pointer in mapped view
    FDefMapSize: NativeInt; // default size of mapping window
    FMemory: PByte;         // address of mapping window
    FFileSize: Int64;       // available file size
  protected
    function GetSize: Int64; override;
    procedure SetSize(const NewSize: Int64); override;
    procedure RemapAtPosition(RemapBase: Int64);
  public
    constructor Create(const AFileName: string; MapWindowSize: NativeInt = 16777216);
    destructor Destroy; override;
    function Read(var Buffer; Count: Integer): Longint; override;
    function Seek(const Offset: Int64; Origin: TSeekOrigin): Int64; override;
    function Write(const Buffer; Count: Integer): Longint; override;
    property FileName: string read FFileName;
  end;

implementation

uses
  Winapi.Windows, System.RTLConsts;

resourcestring
  sMappedFileIsEmpty = 'Can not map view of zero-length file %s.';
  sSeekBeyondRange   = 'File pointer moved beyond file bounds.';
  sFileMappingError  = 'Error mapping view to file.';
  sStreamIsReadOnly  = 'Stream is read-only.';

function Min(A, B: Cardinal): Cardinal;
begin
  Result := A;
  if B < A then
    Result := B
end;

{ TMappedFileStream }

constructor TMappedFileStream.Create(const AFileName: string; MapWindowSize: NativeInt = 16777216);
begin
  inherited Create;
  FHandle := FileOpen(AFileName, fmOpenRead or fmShareDenyWrite);
  if FHandle = INVALID_HANDLE_VALUE then
    raise EFOpenError.CreateResFmt(@SFOpenErrorEx, [ExpandFileName(AFileName), SysErrorMessage(GetLastError)]);
  FFileName := AFileName;
  PCardinal(@FFileSize)^ := GetFileSize(FHandle, PByte(@FFileSize) + 4);
  if FFileSize = 0 then
    raise EFileStreamError.CreateResFmt(@sMappedFileIsEmpty, [ExpandFileName(AFileName)]);
  FMapping := CreateFileMapping(FHandle, nil, PAGE_READONLY, 0, 0, nil);
  RemapAtPosition(FMappedBase);
end;

destructor TMappedFileStream.Destroy;
begin
  if FMemory <> nil then
    UnmapViewOfFile(FMemory);
  CloseHandle(FMapping);
  FileClose(FHandle);
  inherited;
end;

procedure TMappedFileStream.RemapAtPosition(RemapBase: Int64);
var
  OldBase: Int64;
begin
  OldBase := FMappedBase;
  if FMemory <> nil then
    UnmapViewOfFile(FMemory);
  if FFileSize < FDefMapSize then 
  begin
    FMappedSize := FFileSize;
    FMappedBase := 0;
  end else 
  begin
    FMappedSize := FDefMapSize;
    if FFileSize - RemapBase < FDefMapSize then
      FMappedBase := FFileSize - FDefMapSize
    else 
      FMappedBase := RemapBase;
  end;
  FBufferSeek := FBufferSeek - (OldBase - FMappedBase);
  FMemory := MapViewOfFile(FMapping, PAGE_READONLY, Int64Rec(FMappedBase).Hi, Int64Rec(FMappedBase).Lo, FMappedSize);
  if FMemory = nil then
    raise EStreamError.CreateRes(@sFileMappingError);
end;

function TMappedFileStream.GetSize: Int64;
begin
  Result := FFileSize;
end;

function TMappedFileStream.Read(var Buffer; Count: Integer): Longint;
var
  BytesToRead: Integer;
begin
  Result := 0;
  while (Result < Count) and (FMappedBase + FBufferSeek < FFileSize) do 
  begin
    if FBufferSeek >= FMappedSize then
      RemapAtPosition(FMappedBase + FMappedSize);
    BytesToRead := Min(FMappedSize - FBufferSeek, Count - Result);
    Move((FMemory + FBufferSeek)^, (PByte(Buffer) + Result)^, BytesToRead);
    Inc(Result, BytesToRead);
  end;
end;

function TMappedFileStream.Seek(const Offset: Int64; Origin: TSeekOrigin): Int64;
var
  FilePointer: Int64;
begin
  case Origin of
    soCurrent: FilePointer := FMappedBase + FBufferSeek + Offset;
    soEnd: FilePointer := FFileSize + Offset;
  else
    FilePointer := Offset; // soBeginning
  end;
  if (FilePointer < 0) or (FilePointer > FFileSize) then
    raise EStreamError.CreateRes(@sSeekBeyondRange);
  if (FilePointer < FMappedBase) or ((FilePointer - FMappedBase) >= FMappedSize) then 
  begin
    FMappedBase := FilePointer;
    FBufferSeek := 0;
    RemapAtPosition(FMappedBase);
  end else 
    FBufferSeek := FilePointer - FMappedBase;
  Result := FilePointer;
end;

procedure TMappedFileStream.SetSize(const NewSize: Int64);
begin
  raise EStreamError.CreateRes(@sStreamIsReadOnly);
end;

function TMappedFileStream.Write(const Buffer; Count: Integer): Longint;
begin
  raise EStreamError.CreateRes(@sStreamIsReadOnly);
end;

end.
12 ноя 20, 16:18    [22230878]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
defecator
Member

Откуда:
Сообщений: 39394
alekcvp
Dimitry Sibiryakov

Работа с такими файлами принципиально не укладывается в интерфейс TStream.

Серьёзно?..


сибиряков любит поумничать
в то время, как существует пара десятков реализаций mmf поверх TStream
12 ноя 20, 16:47    [22230924]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Vizit0r
Member

Откуда: Одесса
Сообщений: 855
моя реализация, проверенная годами работы.
На маке и линухе работает, на андроиде тоже.

Проверок на права доступа к файлу и т.д. - тут нет, они делаются до этого момента.

Первоначально где-то слизал, потом перепилил. Где - уже не вспомню, очень уж давно это было.

P.S. Меня до сих пор удивляет, что таких вещей нет в базовой поставке.

К сообщению приложен файл (MemMapFile.pas - 5Kb) cкачать

Сообщение было отредактировано: 12 ноя 20, 16:49
12 ноя 20, 16:52    [22230934]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
DmSer
Member

Откуда: Пенза
Сообщений: 1246
Vizit0r
P.S. Меня до сих пор удивляет, что таких вещей нет в базовой поставке.


Какие преимущества оно даёт по сравнению с TFileStream?
12 ноя 20, 17:07    [22230948]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
rgreat
Member

Откуда:
Сообщений: 6312
Угу. Я тоже не понимаю зачем в реальной жизни нужны "маппированные" файлы.
12 ноя 20, 17:12    [22230952]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51775

DmSer
Какие преимущества оно даёт по сравнению с TFileStream?

Никаких.

Posted via ActualForum NNTP Server 1.5

12 ноя 20, 17:13    [22230957]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Ежов Дмитрий Сергеевич
Member

Откуда: Новокузнецк-Москва, Россия
Сообщений: 100
Мне надо, чтобы файлик записался, даже несмотря на то, что процесс умер.
12 ноя 20, 17:17    [22230962]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Ежов Дмитрий Сергеевич
Member

Откуда: Новокузнецк-Москва, Россия
Сообщений: 100
Нашел компонент с Торри по ссылке выше, допилил под использование с файлами, созданными через CreateFile, а не просто область в памяти, все заработало.
12 ноя 20, 17:18    [22230963]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
alekcvp
Member

Откуда:
Сообщений: 2494
rgreat
Угу. Я тоже не понимаю зачем в реальной жизни нужны "маппированные" файлы.

На самом деле, именно в реализации TStream - пользы никакой, а вообще если работать через API, то доступ будет быстрее т.к., как я понимаю, MapViewOfFile() тупо возвращает адрес данных в файловом кэше и исключается лишнее копирование памяти туда-сюда, особенно в случае последовательного доступа.
12 ноя 20, 17:18    [22230964]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
alekcvp
Member

Откуда:
Сообщений: 2494
Ежов Дмитрий Сергеевич
Мне надо, чтобы файлик записался, даже несмотря на то, что процесс умер.

Это можно решить через FlushFileBuffers после записи данных
12 ноя 20, 17:19    [22230966]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Ежов Дмитрий Сергеевич
Member

Откуда: Новокузнецк-Москва, Россия
Сообщений: 100
alekcvp,

Это может решить только венда. Никаких FlushBuffer нет, процесс умер.
12 ноя 20, 17:20    [22230968]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Ежов Дмитрий Сергеевич
Member

Откуда: Новокузнецк-Москва, Россия
Сообщений: 100
На самом деле, маппированный файл глубоко используется в нашей 1С-очке.
https://its.1c.ru/db/metod8dev/content/5860/hdoc

Пользователи сидят клиентами на серверном процессе rphost, который хранит всю их актуальную инфу в сеансовых данных, по факту в памяти. Серверный процесс падает (либо его рубит админ), менеджер сервера обнаруживает это, создает новый серверный процесс, который подтягивает сеансовые, которые уже записала венда.
12 ноя 20, 17:23    [22230969]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51775

alekcvp
как я понимаю, MapViewOfFile() тупо возвращает адрес данных в файловом кэше

Судя по "A mapped view of a file is not guaranteed to be coherent with a file that is
being accessed by the ReadFile or WriteFile function." это не так.

Ежов Дмитрий Сергеевич
Мне надо, чтобы файлик записался, даже несмотря на то, что процесс умер.

Тогда просто всегда пиши WriteLn в паре с Flush.

Ну или почини процесс, чтобы не умирал.

Posted via ActualForum NNTP Server 1.5

12 ноя 20, 17:26    [22230975]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Ежов Дмитрий Сергеевич
Member

Откуда: Новокузнецк-Москва, Россия
Сообщений: 100
мммм, неумирающий серверный процесс в сложных системах, без утечек памяти и кривых сторонних компонентов и кривого легаси от девопса. Что может быть естественней...
12 ноя 20, 17:29    [22230977]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51775

Ежов Дмитрий Сергеевич
Что может быть естественней...

Использование инструментов тестирования и культуры программирования. Кто из дельфинов
нынче на это способен?..

Posted via ActualForum NNTP Server 1.5

12 ноя 20, 17:32    [22230984]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Vizit0r
Member

Откуда: Одесса
Сообщений: 855
DmSer
Vizit0r
P.S. Меня до сих пор удивляет, что таких вещей нет в базовой поставке.


Какие преимущества оно даёт по сравнению с TFileStream?


насколько я помню из результатов изначального сравнения - MMF дает большой прирост к скорости непоследовательного чтения (записи нет). Ну и плюс доступ по указателю упрощает код.
12 ноя 20, 17:58    [22231004]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
alekcvp
Member

Откуда:
Сообщений: 2494
Dimitry Sibiryakov

Судя по "A mapped view of a file is not guaranteed to be coherent with a file that is
being accessed by the ReadFile or WriteFile function." это не так.

Вообще не вижу взаимосвязи.
ReadFile читает данные в буфер и после этого они там не меняются, при изменении файла.
MMF, как я понимаю, отображает всё в живую.
12 ноя 20, 18:14    [22231020]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 51775

alekcvp
Вообще не вижу взаимосвязи.
ReadFile читает данные в буфер и после этого они там не меняются, при изменении файла.

WriteFile пишет данные с системный буфер. Если бы этот буфер отображался сразу на память -
данные в нём должны всегда соответствовать тому, что записало WriteFile. И наоборот: что
записано в MMF, всегда должно получиться из ReadFile.

Posted via ActualForum NNTP Server 1.5

12 ноя 20, 18:26    [22231033]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
rgreat
Member

Откуда:
Сообщений: 6312
Ежов Дмитрий Сергеевич
мммм, неумирающий серверный процесс в сложных системах, без утечек памяти и кривых сторонних компонентов и кривого легаси от девопса. Что может быть естественней...
Даже если так, хранить важные данные надо в транзакционно безопасной среде.
12 ноя 20, 18:30    [22231038]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6176
Ежов Дмитрий Сергеевич
Мне надо, чтобы файлик записался, даже несмотря на то, что процесс умер.
если у вас программа обвалится на каком-то "странном" состоянии, файлы, отображаемые в память, в этом случае не помогут

Ежов Дмитрий Сергеевич
alekcvp,

Это может решить только венда. Никаких FlushBuffer нет, процесс умер.
это не цель FlushBuffer, его цель - зафиксировать какое-то "устойчивое" состояние. Если операция прошла, то как минимум, она зафиксирована в журнале файловой системы
например, классический подход - это "ведение журнала операций + периодическое сохранение всего состояния"

в случае обвала
1. берётся последнее сохранённое состояние,
2. ищется запись в журнале, которая соответствует этому состоянию, и накатываются все операции, сохранённые в журнале после неё

NTFS, кстати, практически по такому же принципу работает
12 ноя 20, 19:48    [22231072]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
НеофитSQL
Member [заблокирован]

Откуда: Маями
Сообщений: 760
Ежов Дмитрий Сергеевич
Мне надо, чтобы файлик записался, даже несмотря на то, что процесс умер.


MMF для этого не предназначен, и не сможет такого гарантировать.
Гарантия записи при смерти юзер процесса появляется после закрытия системного хэндла (HFILE).

Если нужно гарантировать - закрывайте файл (все хэндлы) и открывайте заново. По-другому мне неизвестно.

MMF был первоначально сделан для внутренних нужд Винды, и оптимизации там касаются в основном чтения.
12 ноя 20, 20:16    [22231078]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
_Vasilisk_
Member

Откуда: Украина, Харьков
Сообщений: 12319
Vizit0r
насколько я помню из результатов изначального сравнения - MMF дает большой прирост к скорости непоследовательного чтения
Зависит от того, какими блоками читать. Если по одному байту, то дает, а если по 4096 байт, то выигрыша вообще нет. Т.е. сама операция чтения проходит быстрее, но для MMF тратится куча времени на вызов MapViewOfFile
12 ноя 20, 21:11    [22231109]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
_Vasilisk_
Member

Откуда: Украина, Харьков
Сообщений: 12319
Ежов Дмитрий Сергеевич
мммм, неумирающий серверный процесс в сложных системах, без утечек памяти и кривых сторонних компонентов и кривого легаси от девопса. Что может быть естественней...
Вы не поверите, но у нас именно такие процессы и пишутся
12 ноя 20, 21:12    [22231110]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Vizit0r
Member

Откуда: Одесса
Сообщений: 855
_Vasilisk_
Vizit0r
насколько я помню из результатов изначального сравнения - MMF дает большой прирост к скорости непоследовательного чтения
Зависит от того, какими блоками читать. Если по одному байту, то дает, а если по 4096 байт, то выигрыша вообще нет. Т.е. сама операция чтения проходит быстрее, но для MMF тратится куча времени на вызов MapViewOfFile

по паре кб, но в разных местах файла, и часто-частно.
12 ноя 20, 22:24    [22231137]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
НеофитSQL
Member [заблокирован]

Откуда: Маями
Сообщений: 760
Vizit0r,

а файл, меньше двух гигов, и не sparse?
12 ноя 20, 22:45    [22231141]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
НеофитSQL
Member [заблокирован]

Откуда: Маями
Сообщений: 760
Vizit0r
_Vasilisk_

Зависит от того, какими блоками читать. Если по одному байту, то дает, а если по 4096 байт, то выигрыша вообще нет. Т.е. сама операция чтения проходит быстрее, но для MMF тратится куча времени на вызов MapViewOfFile

по паре кб, но в разных местах файла, и часто-частно.


В этом случае ММФ должен рулить, особенно если working set небольшой.
Работа с памятью намного привычнее и удобнее чем seek/read, и ММФ не требует загрузки всего файла в память.

Без ММФ, если вы выделите массив, и прочитаете туда весь файл чтоб получить удобства памяти, этот массив все равно будет участвовать в ММФ без вашего ведома, только не с первоначальным файлом, а с pagefile. И тогда может оказаться медленнее, т.к. выгрузка в pagefile требует запись на диск, а read-only MMF просто выкидывает старые страницы и читает их заново из оригинала.
12 ноя 20, 22:54    [22231146]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
_Vasilisk_
Member

Откуда: Украина, Харьков
Сообщений: 12319
НеофитSQL
ММФ не требует загрузки всего файла в память.
Требует. Для вас это сюрприз?

Вызовите MapViewOfFile для 100 мегабайт и посмотрите не время візова и на потребляемую память
13 ноя 20, 10:48    [22231277]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Kazantsev Alexey
Member

Откуда:
Сообщений: 4724
_Vasilisk_,

MMF поднимает в память только те данные, к которым происходит обращение. Кроме того, поднятые в память страницы в любой момент могут быть отданы системе, если будет такая необходимость. Если ты последовательно прошелся по всему файлу, то, в зависимости от условий выполнения, в рабочем наборе приложения может быть полный набор страниц файла, но это не то же самое, что выделить буффер и засосать в него весь файл.
13 ноя 20, 11:39    [22231318]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
_Vasilisk_
Member

Откуда: Украина, Харьков
Сообщений: 12319
Kazantsev Alexey
MMF поднимает в память только те данные, к которым происходит обращение
Открой диспетчер задач и посмотри на потребление памяти.

Я когда-то проводил опыты по чтению файла разными кусками и разными способами
13 ноя 20, 12:39    [22231359]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Kazantsev Alexey
Member

Откуда:
Сообщений: 4724
_Vasilisk_,

Рихтера перечитай.

з.ы. Показания диспетчера нужно ещё правильно интерпретировать.
13 ноя 20, 12:49    [22231364]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Vizit0r
Member

Откуда: Одесса
Сообщений: 855
НеофитSQL
Vizit0r,

а файл, меньше двух гигов, и не sparse?

файлы в районе 100-150 мб, а sparce - это имееется в виду фрагментированность? Если да, то специальной дефрагментацией никто не заморачивается, ни я, ни тем более пользователи.
13 ноя 20, 12:50    [22231366]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
НеофитSQL
Member [заблокирован]

Откуда: Маями
Сообщений: 760
Vizit0r
НеофитSQL
Vizit0r,

а файл, меньше двух гигов, и не sparse?

файлы в районе 100-150 мб, а sparce - это имееется в виду фрагментированность? Если да, то специальной дефрагментацией никто не заморачивается, ни я, ни тем более пользователи.


Sparse file - это файлы с дырками, для которых не отведено место на диске. Например, в первом килобайте есть данные, в 100500 килобайте есть данные, а между ними нет ничего, и места на диске не занимает. Дырка при чтении даст нули, а при записи начнет аллокировать кластеры диска, или какие там у конкретной системы единицы аллокации.

Если у вас таких файлов нет, то это не ваш головняк. Фрагментация диска на работу ММФ не влияет, 200МБ позволяет легко работать хоть из 32-бит, хоть из 64
13 ноя 20, 17:44    [22231607]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
НеофитSQL
Member [заблокирован]

Откуда: Маями
Сообщений: 760
_Vasilisk_
Kazantsev Alexey
MMF поднимает в память только те данные, к которым происходит обращение
Открой диспетчер задач и посмотри на потребление памяти.

Я когда-то проводил опыты по чтению файла разными кусками и разными способами


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

для ММФ немедленно выделяется виртуальное пространство (интервал адресов) из пространства процесса.
Сколько начально поднимается с диска, зависит от оптимизаций в конкретной версии винды, возможно где-то описано, я уже не помню.

Вы можете это легко проверить, применив ММФ к файлу больше, чем количество свободной физической памяти на компе.
13 ноя 20, 17:50    [22231613]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
makhaon
Member

Откуда: A galaxy far far away
Сообщений: 3731
в копилку еще вариант (MappedFile.zip):
https://www.nzlab.dk/codesnippets/codesnippets.htm
14 ноя 20, 11:19    [22231953]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4339
Kazantsev Alexey
_Vasilisk_,

Рихтера перечитай.

з.ы. Показания диспетчера нужно ещё правильно интерпретировать.
Шо там интерпретиовать. Открыть файл на 2 гига в 32-бит программе и пробежаться по нему (хэш посчитать, например). Будет OOM.
14 ноя 20, 14:51    [22232053]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
alekcvp
Member

Откуда:
Сообщений: 2494
YuRock
Kazantsev Alexey
_Vasilisk_,
з.ы. Показания диспетчера нужно ещё правильно интерпретировать.
Шо там интерпретиовать. Открыть файл на 2 гига в 32-бит программе и пробежаться по нему (хэш посчитать, например). Будет OOM.

Открыть - это как? Сделать ему MapView на весь объём?.. А зачем, если можно по частям?
14 ноя 20, 16:22    [22232084]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Kazantsev Alexey
Member

Откуда:
Сообщений: 4724
YuRock
Шо там интерпретиовать.

Что там интерпретировать... А потом начинают путать адресное пространство с выделяемой памятью.
14 ноя 20, 16:34    [22232088]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4339
alekcvp
Открыть - это как? Сделать ему MapView на весь объём?
Да.
alekcvp
А зачем, если можно по частям?
В данном случае - для эксперимента. Чтобы убедиться, что не получится видеть только необходимое, открыв всё.
А вообще, могло бы быть полезно для удобства - для передачи в функцию, которая принимает указатель на память и размер. Например, в виндовую CryptHashData.
Было бы прикольно, если бы винда держала бы в памяти только нужный блок, по которому идут обращения. Ну это так - мечты, мечты. Понятно, что это невозможно, т.к. винда знать не знает об этих обращениях.
16 ноя 20, 07:30    [22232582]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
alekcvp
Member

Откуда:
Сообщений: 2494
YuRock

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

1. Так 2 гига - это лимит на размер памяти в x86 винде, если без плясок с бубном. Как ты его весь под файл отдашь?..
2. Ну как бы через ReadFile() ты такое тоже не вычитаешь, т.е. не вижу тут никаких недостатков перед ним.

Сообщение было отредактировано: 16 ноя 20, 10:45
16 ноя 20, 10:48    [22232678]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Kazantsev Alexey
Member

Откуда:
Сообщений: 4724
YuRock
Понятно, что это невозможно, т.к. винда знать не знает об этих обращениях.

Винда-то, как раз, знает. Без этого знания не работал бы пейджинг. В таск менеджере даже счётчик соответствующий есть, Page Faults называется.
16 ноя 20, 13:43    [22232887]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Barmaley57
Member

Откуда: Москва
Сообщений: 5768
ЕМНИП, при стандартном чтении менеджер кэша винды создает секции читаемого файла по 256кб. Это тоже mmf. Как и исполняемые файлы, и динамические библиотеки и пр.
В книжке Руссиновича все это есть.
16 ноя 20, 14:56    [22232978]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4339
alekcvp
Так 2 гига - это лимит на размер памяти в x86 винде
Спасибо, кэп.
alekcvp
через ReadFile() ты такое тоже не вычитаешь, т.е. не вижу тут никаких недостатков перед ним
Я не недостатки искал, а мечтал о преимуществах.
16 ноя 20, 15:20    [22233007]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4339
Kazantsev Alexey
YuRock
Понятно, что это невозможно, т.к. винда знать не знает об этих обращениях.

Винда-то, как раз, знает. Без этого знания не работал бы пейджинг. В таск менеджере даже счётчик соответствующий есть, Page Faults называется.
Это просто счетчик ошибок доступа. Но а вешать костыль на определение, mmf это или нет, и если да - при необходимости дочитывать кусочек - этого винда не делает. И я считаю, что это верно. Хотя и жаль, конечно.
16 ноя 20, 15:26    [22233016]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
Kazantsev Alexey
Member

Откуда:
Сообщений: 4724
YuRock
Это просто счетчик ошибок доступа. Но а вешать костыль на определение, mmf это или нет, и если да - при необходимости дочитывать кусочек - этого винда не делает.

Конечно это счётчкик ошибок доступа. Когда ты мапишь файл, то физические страницы под него не выделяются, а просто резервируется адресное пространство. Затем, при попытке обратится по адресу из зарезервированного диапазона, возникает ошибка доступа т.к. реальной страницы в памяти нет. Система обрабатывает этот случай и подгружает страницу. Таким образом, счётчик увеличивается, а ты получаешь актуальные данные.
16 ноя 20, 16:11    [22233054]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6176
YuRock,

гугли: защищенный режим X86, дескрипторы страниц
17 ноя 20, 00:36    [22233416]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
НеофитSQL
Member [заблокирован]

Откуда: Маями
Сообщений: 760
[quot YuRock#22233016]
Kazantsev Alexey
Но а вешать костыль на определение, mmf это или нет, и если да - при необходимости дочитывать кусочек - этого винда не делает. И я считаю, что это верно. Хотя и жаль, конечно.


С точностью до наоборот.

Все аллокированное виртуальное пространство винды является ММФ. И на каждом кусочке этого пространства стоит костыль.
И когда костыль говорит что данных нет в памяти, винда идет и подкачивает его с диска.

Это как бы основы виртуальной памяти. Не понимая их, очень трудно понять ММФ.
17 ноя 20, 02:50    [22233456]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4339
kealon(Ruslan)
гугли
C какой целью? Зря я в эту тему влез, походу.
17 ноя 20, 08:46    [22233492]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4339
НеофитSQL
Не понимая их, очень трудно понять ММФ.
Прекрасно. Ты мне скажи, как с помощью ММФ и функции CryptHashData посчитать хэш 4гб файла на x86?
17 ноя 20, 08:48    [22233493]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
НеофитSQL
Member [заблокирован]

Откуда: Маями
Сообщений: 760
YuRock
НеофитSQL
Не понимая их, очень трудно понять ММФ.
Прекрасно. Ты мне скажи, как с помощью ММФ и функции CryptHashData посчитать хэш 4гб файла на x86?


Никак. В 32-битной архитектуре адресное пространство не может превышать 4ГБ. У 32-битной винды максимальное пользовательское пространство 3ГБ, по умолчанию 2 ГБ.

Для последовательного доступа ММФ не предлагает никаких преимуществ. Считать можно так:
.. // init hHash
.. // init fp
for( int c = 0; (c = getc(fp)) != EOF && CryptHashData( hHash, &c, 1, 0 ) ; )
  ;
CryptGetHashParam( hHash, HP_HASHVAL, .. );


Функции этого семейства считаются устаревшими, Майкрософт рекомендует пользоваться новыми.
17 ноя 20, 13:36    [22233683]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
YuRock
Member

Откуда: Донецк
Сообщений: 4339
НеофитSQL
YuRock
Прекрасно. Ты мне скажи, как с помощью ММФ и функции CryptHashData посчитать хэш 4гб файла на x86?


Никак.
Спасибо. Это всё, что я хотел уточнить. Для понимания ММФ.
17 ноя 20, 15:13    [22233844]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 6176
YuRock
kealon(Ruslan)
гугли
C какой целью? Зря я в эту тему влез, походу.
обычно читают для общего развития
17 ноя 20, 17:02    [22233967]     Ответить | Цитировать Сообщить модератору
 Re: Файлы, отображаемые в память.  [new]
alekcvp
Member

Откуда:
Сообщений: 2494
упс

Сообщение было отредактировано: 17 ноя 20, 17:14
17 ноя 20, 17:18    [22233985]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3      [все]
Все форумы / Delphi Ответить