Считать текстовый файл с диска

← →
Alex_C (2012-01-29 17:14) [0]

Во времена ДОСа самым быстрым способом считывания текстового файла с диска был BlockRead с максимально установленным размером буфера 64к (по сравнению с ReadLn , который считывал по строкам.)
Вопрос: для WinXP/Win7 - это осталось в силе? Или есть еще более быстрый способ?

← →
Омлет © (2012-01-29 18:43) [1]

http://delphimaster.net/view/2-1318507172/

← →
Dimka Maslov © (2012-01-29 19:11) [2]

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

← →
brother © (2012-01-29 19:29) [3]

> и скорость их работы зависит только от самой операционной
> системы

от ОС??? от железа наверное?

← →
Dimka Maslov © (2012-01-29 19:56) [4]

Под "операционной системой" я понимал совокупность программных и аппаратных средств, имеющихся на данном компьютере.

← →
sniknik © (2012-01-29 21:26) [5]

каждый ламер считает, что тормоза в "системе", а не в его коде/алгоритмах. отсюда все (99.8%) поиски "наибыстрейшего" системного метода... помогает "самооправдываться".

← →
Омлет © (2012-01-29 22:02) [6]

> sniknik © (29.01.12 21:26) [5]

Есть еще синдром оптимизатора, которым страдают многие программисты.

← →
Германн © (2012-01-30 01:32) [7]

> Во времена ДОСа самым быстрым способом считывания текстового
> файла с диска был

Во все времена самым главным вопросом было - "А зачем это нужно?".

← →
Alex_C (2012-01-30 09:49) [8]

> "А зачем это нужно?".

Есть БД сохраненная на диске в текстовом виде. Формат сохранения - нечто типа упрощенного варианта XML. Размер файла от 10 мег и выше. Скорость загрузки файла критична.

← →
sniknik © (2012-01-30 10:40) [9]

> Размер файла от 10 мег и выше.
не проблема для любого, хоть и построчного чтения (все одно буферизация системой делается).

> Формат сохранения - нечто типа упрощенного варианта XML.
а вот и проблема... велосипед! (наверное тоже для "скорости" делался :), и тормоза наверняка в нем, т.к. открытие/разбор 10 мег. нормального xml, обычным idom-документом, вполне быстрая.

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

← →
Palladin © (2012-01-30 11:19) [10]

> т.к. открытие/разбор 10 мег. нормального xml, обычным idom-
> документом, вполне быстрая.

ну я бы не сказал что прямо уж быстрая... когда я перешел на SAX - скорость возросла в десятки раз... если не в сотни...

← →
sniknik © (2012-01-30 12:01) [11]

> когда я перешел на SAX - скорость возросла в десятки раз... если не в сотни...
ридонли/однонаправленный датасет тоже быстрее "полноценного", и что это нам говорит/доказывает?

на таких размерах самый быстрый способ мапить файл в MMF

> мапить файл в MMF

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

> sniknik © (30.01.12 12:01) [11]

сравнение не корректно, парсинг SAXом в свою, необходимую и достаточную, структуру выгодно отличается скоростью от использования DOM

> сравнение не корректно
если так то отредактируй значение в коком нибудь теге и сохрани файл... ?

← →
QAZ (2012-01-31 14:08) [16]

> Есть еще синдром оптимизатора, которым страдают многие программисты.

есть синдром батонокидателя,а это еще хуже :)

Считать текстовый файл с диска Найти похожие ветки