Здравствуйте.

Имеется текстовой файл с записями следующего типа:

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

но сам файл весит 7,5мб и имеет более 150 000 записей.

можно ли считывать сразу только одну строку из файла ? (положение строки рендомное).

fopen, fgets, fseek
но конечно изврат... по хорошему тут только БД поможет =)

А зачем тогда считывать весь файл? Может, ипользовать fgets с рандомным смещением относительно начала файла?

БД использовать пока нет возможности.

а вот то, что можно делать смещение в fgets  я не знал. спасибо  попробуем так 

Ну не совсем в fgets  .  Сначала задать смещение, а затем - вызвать fgets  

только скорее всего после fseek ты попадешь на центр какой нибудь строки, поэтому запускай 2-а раза fgets, и все будет ОК, кроме первой и последней строки в файле!

ну я понел. fseek-ом задаем смещение, потом юзаем fgets   


спасибо за идею  не споткнусь здесь.

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

fseek - о хорошему, вообще для бинарных файлов с четкой структурой. Для строковых ее лучше не использовать...
Знаю, сейчас некоторые тут начнут умничать "ну ведь работает же"... В ПХП много чего работает, даже скрипт с неинициалиированной переменной...

Это сообщение отредактировал(а) Mal Hack - 13.8.2007, 13:24

Вот ты подумал что сказал? Про поточи слышал? Знаешь что такое? fopen открывает не поток?

Diesel Draft, свой хамский тон уйми, пожалуйста. ;)


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

Я очень сильно сомневаюсь, что разработчки в фопен реализовали схему, т.к. на Си фопен 100% работает так, как описано в первом случае, да и тема тут была годичной давности, когда у кого-то из пользователей была проблема использования памяти с большим по объему файлом.

та я там смайл поставить забыл   

Вот ты здесь и не прав. Я помню когда появился РНР5 то в многих статях писало что теперь РНР будет поддерживать потоки, которые раньше только емулирувались.  
Можно проверить. У меня на роботе нет РНР интерпретатора. Поэтому если у тебя есть то помоги парню.
Просто загрузи припустим песню и посмотри на сколько изменились затраты памяти. 

Это не так. Да, fopen() не использует прямой доступ к файлу и не может позиционировать курсор в произвольное место файла, но он никогда не читает сразу весь файл в память. В PHP, конечно, можно позиционировать курсор, но методика несколько иная. При смещении курсора на $offset байт ему приходится прочитать эти $offset байт (что бы прочитать 1кб из середины файла размера 100мб, придется прочитать ~50мб). Т.о. fopen() практически не расходует память, но при использовании fseek() будет загружать винт.
Для работы с прямым доступом к диску можно использовать функции Direct IO Functions


Совершенно согласен, по хорошему fseek() вообще не должен работать в ASCII режиме. И если нету на то особой причины, то лучше всегда читать в бинарном режиме.

спасибо всем отписавшимся.

Mal Hack, можно дать линк с простейшим примером использования потоков при работе с файлами ?


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

Хм... Что-то я такого не помню, подкинь ссылку, посмотрю.


Если только в 5 это поменяли... Раньше такого точно не могло быть. 100%. Тестировал я большие файлы... Точно помню на 4 было так, как в сях.


Если поставить себя на место разработчиков, то мне кажется более лучший вариант, когда  fseek (в случае потоков) искал бы место нужной инфы на диске и давал ее не считывая то, что впереди... Это быстрее.
О такой схеме, я вообще не слышал, на таком низком уровне.

Antarn, sTa1kEr дал ссылку на DIO функции.

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

То что имел ввиду Mal Hack, осуществляется через раширение dio. Простейший пример чтения рандомной строки


Это сообщение отредактировал(а) sTa1kEr - 13.8.2007, 23:13

Сейчас протестировал в Windows. Что бы не писать слишком сложных скриптов, проверял через Task Manager. Файл чуть больше 20мб.

И аналогичный, но через dio.
Через dio, как и ожидалось, все идеально, ни байта лишней памяти, ни одного лишнего обращения к диску. Через fopen, процесс PHP прочел с диска > 80мб данных, а вот памяти сам PHP не съел ни одного лишнего байта, но система съедала где-то еще 4мб, т.е. такое впечатление, что она просто не успевала освобождать память. Если, к примеру, в цикл вставить usleep(100), то же лишняя память не расходовалась. Проверял и на PHP 4 (правда последнем 4.4.7).


Прошу прощенья, тут я забыл добавить, что это только мое предположение, как ведет себя fseek() в PHP. Я не утверждаю, что это так на самом деле, но, имхо, это единственный способ установить курсор в нужную позицию в режиме ASCII.

Это сообщение отредактировал(а) sTa1kEr - 14.8.2007, 00:55

Mal Hack:

А какое тогда отличие от file?

file - обертка фопен, которая расширяет его возможности и читает файл в массив.


У тебя ПХП как модуль апача или как фаст-цгай настроен? Вопрос принципиальный.
Можешь более конкретнее привести цифры с теми параметрами к которым они относятся, чисто ради интереса... Смущают 80 метров как-то...

sTa1kEr, Откуда знание о реализации?


Вот не помню, увижу напишу.



З чего ты взял? Я не не вижу смысла читать весь файл все по дороге за курсором.


Вот тест меня удивил

Я тестировал через CLI и через модуль apache - одинаково.


Могу привести точные цифры использования памяти, добавил в конце скрипта var_dump(win32_ps_stat_proc());

Как узнать в Windows через PHP количество обращений к винту и количество прочитанных данных я не знаю, только разве что через Win32API, но это разве, что когда будет свободное время реализовать. А судя по Task Manager-у 82 003 210 байт прочитано.


Я же сказал, что это мое предположение. Хотя ни что не мешает покопаться исходниках и посмотреть как там реализован fseek()


Если, к примеру, прочитать до оффсета 500 байт в текстовом режиме, то длина прочитаного может быть меньше, к примеру, 450 байт, что может стать причиной ошибок.

Это сообщение отредактировал(а) sTa1kEr - 14.8.2007, 18:34

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

Как выяснилось ~80мб при любом размере файла, т.е. по 8кб на каждый fseek(). Тут определенно надо разобраться.
В Linux-е тот же скрипт так же не увеличивает использование памяти, но как просмотреть обращения к диску я не знаю.

Парне а вы точно то считаете?