Читать файл максимально быстро? странный вопрос))

An unhandled exception occurred at $000000010001D11F: ERangeError: Range check error $000000010001D11F PARSESTRING, line 347 of uzfilestream.pas $000000010000186D TESTMMF, line 48 of streamtest.lpr $00000001000023D1 main, line 89 of streamtest.lpr $0000000100002E96 $000000010000F950 $0000000100001770 $00000000777D59CD $000000007793383D

там арифметика и логика, контроль переполнения включать ненадо

поправка - читать огромный текстовый файл это сродни SQL-выборке миллиона записей и то, и другое, порождает законный вопрос - "зачем?"

есть много текстовых форматов обмена данными, не всё уперлось в бд

я пока что вижу, что задача надуманная

дампы баз, логи...

15 гигов естественно для стресстеста, но до гига вполне в моей работе текстовые файлы проскакивают

а зачем их читать целиком ??

чтобы распарсить

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

DXF - чертеж, пока не прочитаешь целиком - невозможно отобразить

и? зачем парсить сразу такой огромный объём?

так надо

Стикер

Окей. живой пример. лог керио за несколько лет (за определенную дату не умеет выгружать) на 8 гб. плюс собранные логи с компов, в сумме, где-то на 12 Гб. всё это распарсить, чтобы определить чем на самом деле занимался юзер в интернет и локальной сети.

Спасибо Абобе

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

керио это просто не умеет

автодеску. а за ifc емнип Graphisoft

ок, не моя тема... кстати, а пробовали использовать sed ?

тут не проканает, парсинг нужен - чтобы перевести во внутреннее представление, десериализация короче

он никаким боком тут. это просто текстовое представление бинарных данных. нужно всё распарсить. И даже если ты потом чтото выкинешь, это нужно распарсить чтоб понять что можно выкинуть. Никакого оглавления - читать отсих-досих нет. while not eof

Хуже DXF только postscript

ок, но с логами он может помочь (разбить по дате и т.п.)

ещё прелесть подкинуть? csv с более чем 1 млн строк

зато формат достаточно универсален

не особо

нет предела извращенству... кто такие CSV пилит - тому тоже надо задать вопрос "зачем?" )))

зато какой простой формат!

в открытых данных до сих пор выкладывают такие датасеты

формат-то простой, и хороший... но разбивать данные тоже надо

хуже воровства - это про такую простоту))

так там поля разделяются. 1 CSV файл = 1 таблица

этот вопрос исчерпан?

про автокады и иже с ними я понял, остальное надуманно

ковыряли выгрузку из 1с на несколько млн позиций?

что бы ты не надумывал, файлы надо читать максимально быстро))

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

это вы вбили себе в голову

ради того чтобы работало побыстрее. глядишь и разроботчик той бд тоже почешет репу и инсерт ускорится))

ну-да, какая разница сколько будет читаться файл, час или 5 минут. работнику и так зарплата капает, пофиг что его начальник на нервах из-за скорой сдачи отчёта

Стикер

достаточно, чтобы не парицо

10+50

дело не в одном только ммфе. изначально в качестве правильного вариана мне было предложено straem.Read(Result,1) с предложениями не заморачиваться - это медленней в десятки раз

всяко бывает. хотя бы парсинг логов

ну вырвать не вырвать, но не такая уж редкость

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

Стикер

сама прелесть была в том, что лог писался только на системный раздел

Нну, PDF напрмер, тоже текстовый формат.

Ну неправда же, сразу тебе говорил, что MMF. https://t.me/Delphi_Lazarus/318803

имел ввиду штатные делфи\фпц методы