чтение массива double с помощью TFileStream

← →
Ega23 © (2012-01-18 20:08) [40]

> Во-вторых, AssignFile-Reset-Read-CloseFile - это не сложный,
> а, наверное, наоборот, самый простой способ чтения файла
> на Паскале.

1. Речь не о Паскале, а о Delphi 7. И FileStream тут будет гораздо более удобней. И проще. В связи с этим

> Во-первых, я предлагаю не использовать "доводы" типа [32].

вкупе с [31] воспринимается смешно.

> В-третьих, при любом способе (сразу весь или кусками) будет
> буферизация, поэтому разница не должна быть большой

А ты возьми и проверь. На 10 миллионов значений. FileStream - 93 ms. Assign-Read-Close: 16708 ms
Разница не очень большая, всего в 180 раз. Буферизация, тем более... :)

← →
Андреевич (2012-01-18 20:38) [41]

c readln() вообще может получиться адски медленно ( http://forum.sources.ru/index.php?showtopic=326171&view=findpost&p=2848363 :) )

← →
Самуилыч (2012-01-18 21:01) [42]

> Ega23 © (18.01.12 20:08) [40]

Ты бы еще сотню миллиардов чисел взял. Речь идет о конкретной задаче -
и автор четко написал: миллион точек. По твоим же данным это примерно полторы секунды. Аффигительное время, да? Пару раз моргнуть успеешь.

В [25] сказано: "считывание происходит моментально". Что еще нужно?

Ничего. И не надо превращать оптимизацию в самоцель. Спорить тут не о чем.

> Андреевич (18.01.12 20:38) [41]

А что, разве кто сомневался, что текстовый файл - это медленно?

← →
Ega23 © (2012-01-18 21:16) [43]

> Ничего. И не надо превращать оптимизацию в самоцель. Спорить
> тут не о чем.

Где тут оптимизация-то? Абсолютно штатная операция.

> А что, разве кто сомневался, что текстовый файл - это медленно?

Если с умом, то вполне себе быстро.

← →
Самуилыч (2012-01-18 21:55) [44]

> Ega23 © (18.01.12 21:16) [43]

> Где тут оптимизация-то?
Вообще-то, как раз о ней речь с самого начала и идет. Еще с [0].

> Если с умом, то вполне себе быстро.
Не затруднит примерчег быстрого заполнения массива double из текстового файла?

------------

Я тут последовал твоему совету "возьми и проверь". Именно на 10 млн чисел. Вот мои результаты: FileStream - 125 ms. Assign: 62 ms.

Разница не очень большая, всего в 2 раза. Но почему-то в другую сторону. Что я (или не я?) делаю не так?

← →
Jeer © (2012-01-18 22:13) [45]

> Что я (или не я?) делаю не так?

Число процессоров не учитываешь :)

← →
Ega23 © (2012-01-18 22:28) [46]

> Я тут последовал твоему совету "возьми и проверь". Именно
> на 10 млн чисел. Вот мои результаты: FileStream - 125 ms.
> Assign: 62 ms.

Можно код посмотреть?

> Вообще-то, как раз о ней речь с самого начала и идет. Еще с [0].

Я к тому, что "где здесь некая вычурная оптимизация"?

← →
Ega23 © (2012-01-18 22:29) [47]

> Не затруднит примерчег быстрого заполнения массива double
> из текстового файла?

Формат текстового файла приведи, пожалуйста.

← →
Jeer © (2012-01-18 22:49) [48]

Ну как, спецы, оптимизируем ?
Наиболее быстрый способ чтения текстового файла и парсинга в дин. массив ?
type
TCoords = class
X: double; Y: double
end;

var
arCoords: array of TCoords;

Число строк: >= 100 тыс и <= 10 млн.

Формат каждой строки файла - два числа в формате фиксированной точки.
+/-N.9N_+/-N.9N

"_" - символ "пробел" ( #32 )
+/- - знак (плюс может отсутствовать)
N - цифровой символ
. - десятичная точка
9N - число цифровых символов, не более 9, но не менее 1.

Первое число - X, второе - Y.

← →
Ega23 © (2012-01-18 22:52) [49]

> Jeer © (18.01.12 22:49) [48]

Треба уточнение:
1. ANSI или UNICODE?
2. Я правильно понял, что каждый экземпляр TCoords записано отдельной строкой?

← →
Jeer © (2012-01-18 22:56) [50]

1. ANSI, какой на фик уникоде для чисел :)
2. Да, отдельная строка на (*x,*y)

Данные - предположительно шумовой процесс, т.е. число цифр после запятой с большой вероятностью будет именно 9 ( это просто для примера ).

← →
Ega23 © (2012-01-18 23:11) [51]

> 1. ANSI, какой на фик уникоде для чисел :)

Файл-то текстовый...

Я правильно понял, что до запятой только одна цифра?

← →
Dennis I. Komarov © (2012-01-18 23:30) [52]

Сорри за офф, навеяло:
ФаМиРеДоСольСоль :)

← →
Самуилыч (2012-01-18 23:31) [53]

> Ega23 © (18.01.12 22:28) [46]

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

> Я к тому, что "где здесь некая вычурная оптимизация"?
Почему "вычурная"? Обычная оптимизация. Человек написал код, скорость его не устраивает, он спросил, как ускорить - это и есть оптимизация. Вся ветка о ней и есть.

> Ega23 © (18.01.12 22:29) [47]
> Формат текстового файла приведи, пожалуйста.

Снова ай-яй-яй. Ты отвечал на мой ответ на [41], а в [41] четко сказано - readln. Значит, формат очевиден - одно число в строке, в текстовом файле.

← →
Jeer © (2012-01-18 23:35) [54]

> Я правильно понял, что до запятой только одна цифра?

Ну да.

← →
Jeer © (2012-01-18 23:38) [55]

Я к тому, что если уж бодаться, то хотя бы на некоторой более-менее правдоподобно описанной и востребованной ситуации.
Надо было бы конечно ввести более широкое представление чисел, ну и я упростил, но и заложил "мину".

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

← →
Jeer © (2012-01-18 23:50) [56]

> Снова ай-яй-яй.

Слов много, толку мало.
Не образовательно говоришь, а потому бесперспективно..

← →
Inovet © (2012-01-18 23:51) [57]

> [55] Jeer © (18.01.12 23:38)
> т.к. содержит неявное указание на возможность оптимизации
> по размеру файла

В смысле на выделение памяти зараз по предположительному количеству чисел? Я сразу подумал как бы так её выделить чтобы не перевыделять потом и слишком много не хапнуть.

← →
Самуилыч (2012-01-19 01:14) [58]

Навскидку. Наверное, не самое лучшее, но первое, что пришло в голову.

Любая строка в файле не короче 9 символов : N.N_N.N CR LF
Значит, число строк в файле N не более: размер_файла / 9

Создаем TStringList и ставим ему Capacity = N
Потом LoadFromFile - получаем по 2 числа в строке и реальный Count.
Потом SetLength массиву.
Потом в цикле создаем и заполняем элементы массива.

← →
Самуилыч (2012-01-19 01:17) [59]

> Значит, число строк в файле N не более: размер_файла / 9
> Создаем TStringList и ставим ему Capacity = N

Здесь надо заменить N на M, иначе путаница.

← →
Ega23 © (2012-01-19 01:19) [60]

> Можно. Но после того, как скажешь, где я тебя обманул.

детский сад.

← →
Самуилыч (2012-01-19 01:25) [61]

Вообще, можно еще помудрить с элементами массива.

Размер элемента известен: SizeOf(Pointer) + 2 * SizeOf(Double)
Число элеменов тоже известно (см. [58]).

Значит, можно разом выделить память одним экстентом под все элементы массива, а в цикле только заполнять их и проставлять в массив их адреса.

← →
Самуилыч (2012-01-19 01:30) [62]

> Ega23 © (19.01.12 01:19) [60]

Хех... дружище, ООП - штука отличная, но далеко не всегда самая эффективная. Потому что накладных расходов довольно много бывает.

← →
Германн © (2012-01-19 01:33) [63]

> Inovet © (18.01.12 23:51) [57]
>
> > [55] Jeer © (18.01.12 23:38)
> > т.к. содержит неявное указание на возможность оптимизации
> > по размеру файла
>
> В смысле на выделение памяти

Вообще-то в задаче Jeer © (18.01.12 22:49) [48] об оптимизации памяти или о её перераспределении речи не было.

← →
Ega23 © (2012-01-19 01:43) [64]

> ООП - штука отличная, но далеко не всегда самая эффективная.

А где тут ООП?

← →
Самуилыч (2012-01-19 01:53) [65]

> Ega23 © (19.01.12 01:43) [64]

Как? А твой любимый TFileStream - это разве не ООП?

← →
Германн © (2012-01-19 01:54) [66]

> Ega23 © (19.01.12 01:43) [64]

Самиуилыч бредит, ибо это не родное для его время суток.
Он явно путает ООП с чем-то ещё.

← →
Ega23 © (2012-01-19 01:57) [67]

> Как? А твой любимый TFileStream - это разве не ООП?

Честно говоря, я даже и не знаю что сказать.

← →
Самуилыч (2012-01-19 02:17) [68]

> Германн © (19.01.12 01:54) [66]

Купи книжку Архангелького и там прочти, что такое ООП. Потом приходи сдавать зачет.

> Ega23 © (19.01.12 01:57) [67]

Тогда поясню. ООП - это объектно-ориентированное программирование (выучи это наизусть). То есть, программирование с использованием объектов.

Ты использовал экземпляр класса TFileStream. А экземпляр класса есть объект (это тоже выучи наизусть). Значит, ты использовал объект.

Теперь вспомни, что программирование с использованием объектов сокращенно называется ООП. Значит, использовав класс TFileStream, ты тем самым применил ООП.

И расскажи все это Германну, чтобы ему на Архангельского не тратиться.

> Самуилыч (19.01.12 02:17) [68]
>
> > Германн © (19.01.12 01:54) [66]
>
> Купи книжку Архангелького и там прочти, что такое ООП. Потом
> приходи сдавать зачет.

Даже в полном бреду, я себе никак не представляю, что буду сдавать зачёт по Архангельскому. Лучше уж сразу пойти в дворники!

> Самуилыч (19.01.12 02:17) [68]
>
> > Германн © (19.01.12 01:54) [66]

Пардон. Я не оценил вашего юмора.
Но оценил вашу "анонимность"!
Предпочту теперь ваши высказывания не учитывать.

← →
Самуилыч (2012-01-19 02:40) [71]

> Jeer © (18.01.12 22:49) [48]

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

Число строк в файле: не более 10 млн.
Строки ANSI.
Длина каждой строки: не более 27 байт (-N.9N_-N.9N CR LF)
Значит, размер файла не более 270 млн. байт (257 Мб с копейками)

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

← →
Самуилыч (2012-01-19 02:43) [72]

> Германн © (19.01.12 02:32) [70]

Извини, если что. Просто [66] ты зря написал.

Ладно, проехали. Предлагаю мир, дружбу, жвачку. И пиво, само собой.

> Самуилыч (19.01.12 02:43) [72]
>
>
> > Германн © (19.01.12 02:32) [70]
>
> Извини, если что. Просто [66] ты зря написал.
>
> Ладно, проехали. Предлагаю мир, дружбу, жвачку. И пиво,
> само собой.
>

Пиво я не пью!
Если речь только о пиве - то проехали.

> [71] Самуилыч (19.01.12 02:40)
> Это позволяет замаппить файл (памяти должно хватить)

А при чём тут "памяти хваить"? Какая память имеется ввиду?

> Самуилыч (19.01.12 02:40) [71]
..
> Быстрее вряд ли придумаешь.

Код, давай код и тесты - теоретиков и так много на свете, а тут глядишь кому-то поможем с реальной задачей :)

← →
Самуилыч (2012-01-19 10:45) [76]

> Inovet © (19.01.12 09:39) [74]

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

А если я понимаю неправильно, то пусть меня поправят. Не обижусь, еще и спасибо скажу.

← →
Самуилыч (2012-01-19 10:50) [77]

> Jeer © (19.01.12 10:26) [75]
> Код, давай код и тесты - теоретиков и так много на свете,
> а тут глядишь кому-то поможем с реальной задачей :)

Эва... код давай... это ж писать надо, часа 2-3 уйдет, не меньше. А работать за меня Пушкин будет?

Вообще-то, я бы с удовольствием, но не поймут-с... да и Пушкина под рукой нет.

Так что поимку ручного льва в пустыне Сахара придется оставить читателю в качестве самостоятельного упражнения.

> [76] Самуилыч (19.01.12 10:45)
> причем этот диапазон не может превышать свободную память.

Это неправильно.

И вообще сомнительно для последовательного чтения. Короче
> [75] Jeer © (19.01.12 10:26)
> Код, давай код и тесты

← →
Самуилыч (2012-01-19 12:26) [79]

> Inovet © (19.01.12 11:29) [78]

Почему неправильно? Процессу выделяется 4Гб памяти, из них нам доступны нижние 2 Гб (кроме самых нижних 64 Кб, но сейчас это неважно). Допустим, в какой-то момент мы использовали эти 2 Гб почти полностью, осталось 1 Мб. И тут мы патаемся замаппить файл размером 5 Мб, причем все 5 Мб в CreateFileMapping и указываем. А свободных адресов для этого нет - получаем ошибку.

Что тут не так?

← →
Самуилыч (2012-01-19 12:34) [80]

Хотя можно и проще - выделить буфер, равный размеру файла и засосать в него весь файл разом, как советовал Ega23. А потом парсить его, двигая указатель от пробела к пробелу.

чтение массива double с помощью TFileStream Найти похожие ветки