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

← →
Alexander123 © (2012-01-17 18:11) [0]

Имеется текстовый файл с числами. Пытаюсь считать их вот таким способом:
var fs: TFileStream; A: array [0..9] of double; begin if opendialog1.Execute then begin fs:=TFileStream.Create(opendialog1.FileName, fmOpenRead); fs.Read(A[0], sizeof(A)); ...
При дальнейшей работе получаются значения которых не было в файле. Как решить проблему? Или обязательно считывать данные как byte и потом уже переводить в double?

← →
Германн © (2012-01-17 18:29) [1]

> Имеется текстовый файл с числами

Текст нужно читать как текст, а не как числа.

← →
Anatoly Podgoretsky © (2012-01-17 18:32) [2]

> Alexander123 (17.01.2012 18:11:00) [0]

Используй тип Текстовый файл.

← →
Alexander123 © (2012-01-17 18:52) [3]

> Германн © (17.01.12 18:29) [1]

т.е. надо считать данные из файла как массив byte, потом найти в нем символы, соответствующие цифрам (чтобы избавится от пробелов) и далее переводить в double? есть ли более простой способ?

← →
Dimka Maslov © (2012-01-17 18:52) [4]

> Используй тип Текстовый файл.

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

← →
Германн © (2012-01-17 18:56) [5]

> есть ли более простой способ?
>

Если файл действительно текстовый, то проще Read или Readln ничего не придумано.

← →
Alexander123 © (2012-01-17 19:02) [6]

> Если файл действительно текстовый, то проще Read или Readln
> ничего не придумано.

файл действительно текстовый
но проблема в том, что с большими файлами read и readln работает довольно медленно
пытаюсь ускорить работу

← →
Dimka Maslov © (2012-01-17 19:08) [7]

> пытаюсь ускорить работу

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

← →
Alexander123 © (2012-01-17 19:17) [8]

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

число 10 я тут от балды поставил) с маленькими файлами проще проверять правильность работы
реально приходится работать с файлами, состоящими, например, из миллиона точек
и вот тут уже важна и скорость работы

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

> реально приходится работать с файлами, состоящими, например,
> из миллиона точек

Так их и надо писать изначально не в виде текста, а в виде набора double

← →
Dimka Maslov © (2012-01-17 19:23) [10]

> реально приходится работать с файлами, состоящими, например,
> из миллиона точек

Тогда - либо действительно изначально создаём файл в виде набора double, либо читаем побайтно, преобразуя строки в числа. Впрочем read/readln так и поступают. Тут уже не убыстрится.

← →
Alexander123 © (2012-01-17 19:25) [11]

> Так их и надо писать изначально не в виде текста, а в виде
> набора double

это уже другая программа их записывает в таком виде
может сам файл возможно как-то конвертировать?

← →
Ega23 © (2012-01-17 19:29) [12]

Не, если файл чётко структурирован, то ускорить, пожалуй, можно.
Например, число (строго 5 символов до разделителя, разделитель строго запятая, строго 8 символов после разделителя), дЖва пробела, число, ..., 10-е число, перевод строки (строго #13#10).
Тогда можно ускорить. Но на копейки.

← →
Ega23 © (2012-01-17 19:29) [13]

> может сам файл возможно как-то конвертировать?

Тогда это будет уже 3-я программа. :)

← →
Dimka Maslov © (2012-01-17 19:30) [14]

> может сам файл возможно как-то конвертировать?

Написать прогу, которая читает текст и записывает в другой файл двоичные данные?

← →
Anatoly Podgoretsky © (2012-01-17 21:36) [15]

> > Используй тип Текстовый файл.
>
>
> Для компьютера все файлы суть двоичные. Текстовость файла
> это проблема интерпретации. Следовательно, при правильной
> интерпретации массив доубле можно прочесть при помощт тфилестреам.
>

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

Read(F, A[I])

← →
sniknik © (2012-01-17 23:02) [16]

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

← →
Dennis I. Komarov © (2012-01-17 23:11) [17]

> sniknik © (17.01.12 23:02) [16]

так все и рассказали в [0] (как обычно :))
11 45678 5554 555545 77766 {bla bla ....{очень много}... bla}#13#10 B64[тут еще комент или Bitmap] ................ 776876 77776 767878 76988

← →
sniknik © (2012-01-18 00:17) [18]

> 11 45678 5554 555545 77766 {bla bla ....{очень много}... bla}#13#10
???
Ega23 © (17.01.12 19:19) [9]
> Так их и надо писать изначально не в виде текста, а в виде набора double

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

> Alexander123 © (17.01.12 18:11)

Лучше всего сразу писать числа не как текст, а именно как числа, тогда они и пушутся быстрее, и читаются тоже быстрее (потому что не просходит преобразования чисел в строки и обратно):
var A: array [N..M] of double; F: file of double; i: integer; begin AssignFile(F, "имя файла"); Rewrite(F); for i := N to M do Write(F, A[i]); CloseFile(F); end;
var A: array [N..M] of double; F: file of double; i: integer; begin AssignFile(F, "имя файла"); Reset(F); for i := N to M do Read(F, A[i]); CloseFile(F); end;
Но если текстовый файл уже есть, то читать его можно так:
var A: array [N..M] of double; F: TextFile; i: integer; begin AssignFile(F, "имя файла"); Reset(F); for i := N to M do Read(F, A[i]); // Если числа разделены пробелами // ReadLn(A[i]); // Если каждое число с новой строки CloseFile(F); end;

← →
Германн © (2012-01-18 01:12) [20]

> Самуилыч (18.01.12 00:58) [19]

Имхо, лучше всегда записывать с разделителями. Может это и чуть более медленный вариант (не экспериментировал), а может и чуть менее медленный. Как этот Compile Magic поймёшь. :)
Но зато при просмотре в блокноте проблем не будет. Что немаловажно автору для проверки его алгоритма.

← →
Германн © (2012-01-18 01:21) [21]

> Alexander123 © (17.01.12 19:25) [11]
>
>
> > Так их и надо писать изначально не в виде текста, а в
> виде
> > набора double
>
> это уже другая программа их записывает в таком виде
> может сам файл возможно как-то конвертировать?
>

Можно. Но вопрос - нужно ли? Если обработка данных конкретного эксперимента - разовая задача, то не нужно. Всё равно сначала нужно будет потратить время на считывание текстового файла текстовыми способами. А потом ещё потратить время на запись чисто двоичного файла. А потом его заново читать ещё придётся.
А вот если эти данные предназначены для многократного считывания, то есть смысл один раз сей файл преобразовать, а потом уже N раз работать с файлом типа File of Double или просто File.
Имхо2. Не уверен что чтение с помощью класса TFileStream в данном случае будет быстрее старого, доброго BlockRead.

← →
Ega23 © (2012-01-18 02:11) [22]

> Самуилыч (18.01.12 00:58) [19]

Зачем так сложно?

procedure TForm12.Button1Click(Sender: TObject); var arr: array of Double; i, cnt: Integer; fs: TFileStream; begin cnt := StrToInt(Edit1.Text); SetLength(arr, cnt); for i := 0 to cnt - 1 do arr[i] := (i + 1)/10; fs := TFileStream.Create("c:\temp\1.dat", fmCreate); try fs.WriteBuffer(cnt, SizeOf(Integer)); if cnt > 0 then fs.WriteBuffer(arr[0], cnt * SizeOf(Double)); finally fs.Free; end; end; procedure TForm12.Button2Click(Sender: TObject); var arr: array of Double; i, cnt: Integer; fs: TFileStream; begin fs := TFileStream.Create("c:\temp\1.dat", fmOpenRead or fmShareDenyNone); try fs.ReadBuffer(cnt, SizeOf(Integer)); if cnt = 0 then Exit; SetLength(arr, cnt); fs.ReadBuffer(arr[0], cnt * SizeOf(Double)); Memo1.Clear; for i := 0 to cnt - 1 do Memo1.Lines.Add(FloatToStr(arr[i])); finally fs.Free; end; end;

← →
Ega23 © (2012-01-18 02:13) [23]

> а потом уже N раз работать с файлом типа File of Double

Нафига файловые операции туда-сюда дёргать? Зачитал разом в память, а там уже работай сколько влезет.

← →
Германн © (2012-01-18 02:32) [24]

> Ega23 © (18.01.12 02:13) [23]
>
>
> > а потом уже N раз работать с файлом типа File of Double
>
>
> Нафига файловые операции туда-сюда дёргать?

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

← →
Alexander123 © (2012-01-18 09:49) [25]

Всем спасибо за ответы.
Оказалось, что я сам себе проблему придумал)) readln, оказывается, работает достаточно быстро. Значительное замедление программы у меня происходило после добавления считанных точек на график. Я думал, что если данные уже считались в память и произошло их преобразование в дабл, то существенных тормозов не должно быть. Делал это следующим образом:
procedure TForm1.Button1Click(Sender: TObject); var f: textfile; x,y: double; begin if opendialog1.Execute then begin assignfile(f, opendialog1.FileName); reset(f); while not eof(f) do begin readln(f,x,y); series1.AddXY(x,y); end; end; closefile(f); end;
Если файл размером несколько Мб, то график строится очень медленно, но если убрать строчку addxy(), то само считывание происходит моментально.

Погуглил и нашел некоторые рекомендации по этому поводу
http://www.delphigroups.info/2/7/359178.html
пример программы как лучше добавлять точки, смысл этого в том, чтобы избегать использование addXY():
Var X,Y : Array of Double; // TChartValues t : Integer; Num : Integer; begin { 1M points } Num:= 1000000; { allocate our custom arrays } SetLength(X,Num); SetLength(Y,Num); { fill data in our custom arrays } X[0]:=0; Y[0]:=Random(10000); for t:=1 to Num-1 do begin X[t]:=t; Y[t]:=Y[t-1]+Random(101)-50; end; { set our X array } With Series1.XValues do begin Value:=TChartValues(X); Count:=Num; Modified:=True; end; { set our Y array } With Series1.YValues do begin Value:=TChartValues(Y); Count:=Num; Modified:=True; end; { Show data } Series1.Repaint;

PS: TChartValues(X) у меня не работает, похоже надо TChart обновить

← →
Dimka Maslov © (2012-01-18 10:40) [26]

> Если файл размером несколько Мб, то график строится очень
> медленно, но если убрать строчку addxy(),

Наверняка у TChart есть метод типа BeginUpdate, который блокирует перерисовку и прочие лишние вещи при массовой модификации данных.

← →
sniknik © (2012-01-18 10:50) [27]

> смысл этого в том, чтобы избегать использование addXY():
поищи другой смысл... ну например чтобы добавлять не точки, рекордсет к примеру.

← →
Inovet © (2012-01-18 11:06) [28]

> [25] Alexander123 © (18.01.12 09:49)

Эта, текст форматировать желательно, а то ведь глаза ломаются, не за что зацепиться. Например так:
Var X,Y : Array of Double; // TChartValues t : Integer; Num : Integer; begin // 1M points Num:= 1000000; // allocate our custom arrays SetLength(X,Num); SetLength(Y,Num); // fill data in our custom arrays X[0]:=0; Y[0]:=Random(10000); for t:=1 to Num-1 do begin X[t]:=t; Y[t]:=Y[t-1]+Random(101)-50; end; // set our X array With Series1.XValues do begin Value:=TChartValues(X); Count:=Num; Modified:=True; end; // set our Y array With Series1.YValues do begin Value:=TChartValues(Y); Count:=Num; Modified:=True; end; // Show data Series1.Repaint;
Сразу видно - чего-то не хватает. И у читающих больше желания просмотреть и вникнуть.

← →
bumbum (2012-01-18 11:35) [29]

И я предложу свой вариант:

var s: TStringList; begin s:= TStringList.Create; if opendialog1.Execute then s.LoadFromFile(opendialog1.FileName);

← →
Ega23 © (2012-01-18 11:40) [30]

> Спроси у своего отца, Олег. Достаточно ли физику один раз
> считать файл с данными, чтобы "нормально" обработать результаты
> некоего "физэксперимента"?

А чё его спрашивать, я ему несколько тулз писал , пока лаборантом работал. Вполне достаточно, если файл нормально структурирован.

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

> Ega23 © (18.01.12 02:11) [22]
> Зачем так сложно?

AssignFile, Reset, Read, CloseFile - ЭТО сложно?
Хм... или LOL ?

← →
Ega23 © (2012-01-18 11:57) [32]

> AssignFile, Reset, Read, CloseFile - ЭТО сложно?

На асме сразу пиши, там, в целом, тоже ничего сложного нет.

← →
Dennis I. Komarov © (2012-01-18 11:58) [33]

> sniknik © (18.01.12 00:17) [18]

само собой, но [11] же...

← →
sniknik © (2012-01-18 12:32) [34]

> но [11] же...
и что? рекорсед это такой же набор данных как массив например. все воспринимают его как "= база", но это неправильно. читать не в массив, а в рекордсет и все дела. проблема?

← →
sniknik © (2012-01-18 12:34) [35]

> читать не в массив
+
а если и сохранять как рекордсет, то и с чтением меньше мороки.

← →
Самуилыч (2012-01-18 16:34) [36]

> Ega23 © (18.01.12 11:57) [32]

Дружище, фии... ведь это уже демагогия... некрасиво же. Ай-яй-яй.

← →
Ega23 © (2012-01-18 16:53) [37]

> ведь это уже демагогия... некрасиво же. Ай-яй-яй.

Ты предлагаешь сравнить варианты с последовательным чтением каждого double, или чтения целиком?

← →
Dennis I. Komarov © (2012-01-18 17:53) [38]

> sniknik © (18.01.12 12:32) [34]

У меня?
У меня нет такого файла, и я даже не знаю его структуры. Откуда могут у меня появится проблемы. :)

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

> Ega23 © (18.01.12 16:53) [37]

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

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

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

← →
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, иначе путаница.

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

детский сад.

← →
Самуилыч (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]

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

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

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

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

А где тут ООП?

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

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

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

> Как? А твой любимый 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. А потом парсить его, двигая указатель от пробела к пробелу.

> [79] Самуилыч (19.01.12 12:26)
> А свободных адресов для этого нет - получаем ошибку.
>
> Что тут не так?

Ты говорил о

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

Если о адресах речь то это и так ясно, а то можно подумать о ещё какой-нибудь памяти.

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

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

> [80] Самуилыч (19.01.12 12:34)
> выделить буфер, равный размеру файл

Зачем столько много, достаточно и размером с кластер.

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

> Inovet © (19.01.12 12:43) [83]

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

> [84] Самуилыч (19.01.12 13:53)
> это последнее число будет нужно как-то сращивать

читаешь следующюю порцию в буфер и прдолжаешь парсить.

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