Какой способ быстрее загрузить файл в память?

@xxxkrikxxx · Регистрация: 12.02.2014

Author24 — интернет-сервис помощи студентам

Здравстуйте. На данный момент непобходио для проекта загрузить файл в память.

Выделил для себя пару методов:
Первый используя TFilesStream и TMemoryStream.

Delphi

var
fs: TFileStream;
ms: TMemortyStream;
begin
fs := TFilesStream.Create('C:\file1.log', fmOpenRead);
ms := TMemortyStream.Create;
fs.Position := 0;
ms.CopyFrom(fs, fs.Size);
 
// ---- делаем что-то
 
ms.Free;
fs.Free;
end;

Однако обнаружил для себя, что у MemoryStream уже есть метод LoadFromFile, где достаточно

Delphi

var
ms: TMemortyStream;
begin
ms := TMemortyStream.Create;
 
ms.LoadFromFile('C:\file1.log');
 
// ---- делаем что-то
 
ms.Free;
end;

Какой из способов будет быстрее грузить файлы, если буду работать с большими файлами? Или может есть еще более быстрые способы, через что-то другое?

@mss · 13.10.2015, 15:12

Сообщение от xxxkrikxxx

если буду работать с большими файлами

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

@xxxkrikxxx · 13.10.2015, 15:23 **[ТС]**

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

@Fulcrum_013 · 13.10.2015, 15:34

Сообщение от xxxkrikxxx

Какой из способов будет быстрее грузить файлы, если буду работать с большими файлами?

Второй способ имеет внутри первый.

@mss · 13.10.2015, 15:49

Сообщение от xxxkrikxxx

сжатая информация, которую нужно разархивировать

Вообще-то "сжатие" и "архивация" - не всегда пересекающиеся понятия.

Первое может подразумевать или не подразумевать второе, равно как и наоборот.

Сообщение от xxxkrikxxx

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

К физической тебя ОС не пустит - у тебя есть доступ только к виртуальной.

@NIKOLAYY · 13.10.2015, 15:53

Сообщение от xxxkrikxxx

На данный момент непобходио для проекта загрузить файл в память.
Выделил для себя пару методов:
Первый используя TFilesStream и TMemoryStream.

Если файл текстовой то есть еще третий способ загрузить его в TStringList
Есть конечно еще и другие способы, все от ситуации зависит.

@Fulcrum_013 · 13.10.2015, 16:01

Сообщение от xxxkrikxxx

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

А обращений сколько будет столько и останется. Даже при том что будете читать напрямую из файлового стрима. Другое дело что при подгрузке всего и сразу оно сразу все в памяти перед началом распаковки, а если тянуть из файла в момент распаковки то возможно ожидание данных, так как только одному цифровому Ктулуху известно насколько упреждающее кеширование ОС и HDD предугадает то что вам нужно. Хотя как понимаю распакованная версия займет еще 500Мб если не больше?
Формат упаковки какой и поддерживает ли он распаковку по фреймам? Если имеет то наверное имеет смысл работать пофреймово. видюхи к примеру держат и трансферят текстуры по трассе память-кеш в запакованном виде а распаковку/запаковку производят на лету во время обработки. так получается быстрее чем трансферить по шине нежатое.

@xxxkrikxxx · 14.10.2015, 07:30 **[ТС]**

В общих чертах структура файла такая:
1) Статистическая информация о файле, где описывается сколько байт файл, сколько объектов всего в файле, с какого по какое время инфа и т.п. Это все записанно в структуре 144 байт.
--------
2) Определение объекта. Структура из 16 байт
3) Заголовок объекта. Структура из 16 байт
4) Блок информации сжатый ZLib.
После распаковки блока 4:
4.1) Определение объекта 16 байт
4.2) Заголовок объекта. Структура из 16 байт
4.3) Сообщение
---------
Далее повторяются блоки с 2 по 4.3. Также все еще усложняется тем, что сжатая информация может содержать не все подпункты 4.1, 4.2, 4.3, а например только 4.1, а в следующем объекте его продолжение, но это уже другой вопрос. Также теоретически возможны блоки информации отличные от этого (например информация не сжата и может быть другой тип объекта), но пока я таких не видел, при расшифровке файлов. Возможно и не будет их в проекте.

@mss · 14.10.2015, 08:17

При такой структуре тем более нефих его в память целиком грузить..
Последовательно считываешь структуру за структурой и раскладываешь ее по полкам

@mss 3530 / 2270 / 279 Регистрация: 24.12.2010 Сообщений: 13,723
	13.10.2015, 15:12	2
	Сообщение от xxxkrikxxx если буду работать с большими файлами Насколько большими ? И есть ли аргументированный довод в пользу необходимости грузить все это хозяйство в память именно целиком, а не поблочно или даже построчно ? 0

@xxxkrikxxx 0 / 0 / 0 Регистрация: 12.02.2014 Сообщений: 35
	13.10.2015, 15:23 [ТС]	3
	Ну может достигать где-то 50 мб, но дело в том, что в этом файле уже содержится сжатая информация, которую нужно разархивировать и обрабатывать. Все это нужно грузить сразу в память, потому что идет обработка всего файла и если меньше обращаться к физической памяти, по логике, должна возрасти скорость обработки данных. Или я не прав? Вообще в файле содержиться лог сигналов. Нужно получить эти данные потом на графике (но я пока до этого не дошел) 0

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	13.10.2015, 15:34	4
	Сообщение от xxxkrikxxx Какой из способов будет быстрее грузить файлы, если буду работать с большими файлами? Второй способ имеет внутри первый. 0

@mss 3530 / 2270 / 279 Регистрация: 24.12.2010 Сообщений: 13,723
	13.10.2015, 15:49	5
	Сообщение от xxxkrikxxx сжатая информация, которую нужно разархивировать Вообще-то "сжатие" и "архивация" - не всегда пересекающиеся понятия. Первое может подразумевать или не подразумевать второе, равно как и наоборот. Сообщение от xxxkrikxxx если меньше обращаться к физической памяти, по логике, должна возрасти скорость обработки данных. Или я не прав? К физической тебя ОС не пустит - у тебя есть доступ только к виртуальной. 0

@NIKOLAYY 844 / 739 / 342 Регистрация: 22.09.2012 Сообщений: 5,034
	13.10.2015, 15:53	6
	Сообщение от xxxkrikxxx На данный момент непобходио для проекта загрузить файл в память. Выделил для себя пару методов: Первый используя TFilesStream и TMemoryStream. Если файл текстовой то есть еще третий способ загрузить его в TStringList Есть конечно еще и другие способы, все от ситуации зависит. 0

@Fulcrum_013 2082 / 1573 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	13.10.2015, 16:01	7
	Сообщение от xxxkrikxxx Все это нужно грузить сразу в память, потому что идет обработка всего файла и если меньше обращаться к физической памяти, по логике, должна возрасти скорость обработки данных. А обращений сколько будет столько и останется. Даже при том что будете читать напрямую из файлового стрима. Другое дело что при подгрузке всего и сразу оно сразу все в памяти перед началом распаковки, а если тянуть из файла в момент распаковки то возможно ожидание данных, так как только одному цифровому Ктулуху известно насколько упреждающее кеширование ОС и HDD предугадает то что вам нужно. Хотя как понимаю распакованная версия займет еще 500Мб если не больше? Формат упаковки какой и поддерживает ли он распаковку по фреймам? Если имеет то наверное имеет смысл работать пофреймово. видюхи к примеру держат и трансферят текстуры по трассе память-кеш в запакованном виде а распаковку/запаковку производят на лету во время обработки. так получается быстрее чем трансферить по шине нежатое. 0

@xxxkrikxxx 0 / 0 / 0 Регистрация: 12.02.2014 Сообщений: 35
	14.10.2015, 07:30 [ТС]	8
	В общих чертах структура файла такая: 1) Статистическая информация о файле, где описывается сколько байт файл, сколько объектов всего в файле, с какого по какое время инфа и т.п. Это все записанно в структуре 144 байт. -------- 2) Определение объекта. Структура из 16 байт 3) Заголовок объекта. Структура из 16 байт 4) Блок информации сжатый ZLib. После распаковки блока 4: 4.1) Определение объекта 16 байт 4.2) Заголовок объекта. Структура из 16 байт 4.3) Сообщение --------- Далее повторяются блоки с 2 по 4.3. Также все еще усложняется тем, что сжатая информация может содержать не все подпункты 4.1, 4.2, 4.3, а например только 4.1, а в следующем объекте его продолжение, но это уже другой вопрос. Также теоретически возможны блоки информации отличные от этого (например информация не сжата и может быть другой тип объекта), но пока я таких не видел, при расшифровке файлов. Возможно и не будет их в проекте. 0

@mss 3530 / 2270 / 279 Регистрация: 24.12.2010 Сообщений: 13,723
	14.10.2015, 08:17	9
	При такой структуре тем более нефих его в память целиком грузить.. Последовательно считываешь структуру за структурой и раскладываешь ее по полкам 0