ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / быстрый поиск в файле
25 сообщений из 38, страница 1 из 2
  1  все
быстрый поиск в файле
    #34095030
Гость1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость1111
Гость
Привет, All!

Подскажите, плз, ламеру в джаве - как сделать быстрй поиск текста в файле?
файл 100М, пробовал что-то типа:

FileReader fr = new FileReader (fpath);
BufferedReader br = new BufferedReader(file_name);
String s;
while ((s = br.readLine()) != null) {
boolean fl_a = false;
if (s.length() != 0) {
String sa = s.substring(0,9).trim();
if (sa.equals(search_string)) fl_a = true;
...

сек 20 лопатит...-(

заранее благодарен!
...
Рейтинг: 0 / 0
31.10.2006, 16:41:40
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095128
он же
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
он же
Участник
RandomAccessFile, метод read
...
Рейтинг: 0 / 0
31.10.2006, 17:02:04
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095215
Гость1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость1111
Гость
Доступно и понятно ;)
тнкс а лот...примерчика какого не будет? чем, вернее насколько данный метод быстрее будет?
...
Рейтинг: 0 / 0
31.10.2006, 17:18:50
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095267
он же
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
он же
Участник
Гость1111Доступно и понятно ;)
тнкс а лот...примерчика какого не будет? чем, вернее насколько данный метод быстрее будет?
Через 5 минут после прочтения вашего первого сообщения, я впервые узнал о существовании такого класса и успел разобраться, как с его помощью можно решить вашу задачу.
Не вижу причин, чтобы вы делали по другому.
...
Рейтинг: 0 / 0
31.10.2006, 17:30:17
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095276
он же
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
он же
Участник
Более того - я успел протестировать скорость работы - она довольно высока (не более 1.5 секунд на чтение 120-ти мегабайтного файла)
...
Рейтинг: 0 / 0
31.10.2006, 17:31:28
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095299
Гость1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость1111
Гость
Спасибо еще раз. теперь есть критерий ориентировочный - открою доку -)
...
Рейтинг: 0 / 0
31.10.2006, 17:37:52
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095478
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
он же
Через 5 минут после прочтения вашего первого сообщения, я впервые узнал о существовании такого класса и успел разобраться, как с его помощью можно решить вашу задачу.


Знаком с этим классом много лет, но сомневаюсь, что RandomAccessFile поможет реализовать задачу поиска текста в файле. Этот класс дает возможность огранизовать доступ к произвольному месту в файле на чтение или запись, но как это поможет при поиске текста ?
Если Вы заранее знаете место расположение текста в файле, тогда понятно :)
...
Рейтинг: 0 / 0
31.10.2006, 18:22:42
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095510
он же
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
он же
Участник
Kachalov
Знаком с этим классом много лет, но сомневаюсь, что RandomAccessFile поможет реализовать задачу поиска текста в файле. Этот класс дает возможность огранизовать доступ к произвольному месту в файле на чтение или запись, но как это поможет при поиске текста ?
Если Вы заранее знаете место расположение текста в файле, тогда понятно :)
Ну что вы в самом деле.
Не писали в детстве свой regexp на паскале?
Там не было ничего кроме возможности максимально быстро получить набор байтиков из файла.

Я смотрю, в Java ситуация ровно такая же. Хочешь чтобы всё максимально быстро и эффективно работало - пиши своё. И это хорошо.
...
Рейтинг: 0 / 0
31.10.2006, 18:31:56
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095511
Гость1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость1111
Гость
Kachalov он же
Через 5 минут после прочтения вашего первого сообщения, я впервые узнал о существовании такого класса и успел разобраться, как с его помощью можно решить вашу задачу.


Знаком с этим классом много лет, но сомневаюсь, что RandomAccessFile поможет реализовать задачу поиска текста в файле. Этот класс дает возможность огранизовать доступ к произвольному месту в файле на чтение или запись, но как это поможет при поиске текста ?
Если Вы заранее знаете место расположение текста в файле, тогда понятно :)

И что Вы можете порекомендовать?
...
Рейтинг: 0 / 0
31.10.2006, 18:32:32
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095518
он же
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
он же
Участник
Причем непонятно - у автора файл типизированный или нет?
Это просто текст в разнобой?
Нужно искать просто какую-то уникальную строку?
...
Рейтинг: 0 / 0
31.10.2006, 18:33:55
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095562
Гость1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость1111
Гость
файл типизированный 46 байт в строке, затем CR
...
Рейтинг: 0 / 0
31.10.2006, 18:50:29
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095703
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
Гость1111файл типизированный 46 байт в строке, затем CR
- это очень хорошо! это дает возможность легко разбить файл на блоки (кратные 47), которые будут анализироваться отдельно (параллельно).

Когда то мне поставили задачу парсить гигабайтных размеров текстовый файл со статистикой. Для анализа больших файлов можно разбивать их на куски (тут действительно поможет RandomAccessFile), а каждый кусок анализировать в отдельном потоке, т. е. создать многопоточное приложение. Правда здесь возникают другие проблемы, лимитом скорости обработки становится не жесткий диск, а недостаток мощности процессора, т. е. достигается почти 100% загрузка процессора.
...
Рейтинг: 0 / 0
31.10.2006, 20:04:33
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095727
он же
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
он же
Участник
А если не хочется заморачиваться с потоками - можно просто читать Nx(46+1) и сравнивать без проблем :)
Будет очень быстро.
...
Рейтинг: 0 / 0
31.10.2006, 20:17:38
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095743
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
он жеБудет очень быстро.
- быстрее чем BufferedReader не будет. Проверено. При линейном чтении файла использование этого потока дает максимально возможный эффект (размер буфера по умолчанию 256, что не хуже чем 47).

- еще один путь повышения эффективности - аккуратные действия со строками. Substring, trim, не дай Бог match, при многократном вызове заметно замедляют программу, попробуйте indexOf - он работает быстрее!
...
Рейтинг: 0 / 0
31.10.2006, 20:32:05
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095815
он же
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
он же
Участник
читать не линейно, а блоками :)
...
Рейтинг: 0 / 0
31.10.2006, 21:20:15
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095816
Гость1111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость1111
Гость
Kachalov он жеБудет очень быстро.
- быстрее чем BufferedReader не будет. Проверено. При линейном чтении файла использование этого потока дает максимально возможный эффект (размер буфера по умолчанию 256, что не хуже чем 47).

- еще один путь повышения эффективности - аккуратные действия со строками. Substring, trim, не дай Бог match, при многократном вызове заметно замедляют программу, попробуйте indexOf - он работает быстрее!

Да, но я вроде как BufferedReader с его readline и использовал...
indexOf конечно попробую, но думается заметно быстрее не будет...

А что посоветутете если загонять данные в байтмассив по 1М и далее читать его в цикле? Понимаю, что вопросы ламерские...-)
...
Рейтинг: 0 / 0
31.10.2006, 21:22:25
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095853
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
Гость1111Да, но я вроде как BufferedReader с его readline и использовал...
indexOf конечно попробую, но думается заметно быстрее не будет...

- будет, будет. 100Mb/47byte=2.2 млн. строк. Если 2 миллиона раз выполнять не оптимизированые действия можно много потерять в производительности.
Гость1111
А что посоветутете если загонять данные в байтмассив по 1М и далее читать его в цикле? Понимаю, что вопросы ламерские...-)
- вопрос не ламерский :) Не попробовав не ответишь. Я уже попробовал :( Это почти ничем не отличается по быстродействию от BufferedReader, хотя возможны варианты в зависимости от того какие жесткие диски Вы используете.
...
Рейтинг: 0 / 0
31.10.2006, 21:51:28
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095862
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
он жечитать не линейно, а блоками :)
- а блоками читать как? по очереди? т. е. линейно как при наличии буфера, только буфер будет не 256 байт как по умолчанию в буферизованых потоках, а 47, кстати размер буфера в буферизованых потоках можно менять, задайте его в 47 байт и Вы увидите, что ничего не изменилось.

- а если блоки читать паралельно, по моему, никак без многопоточности не обойтись.
...
Рейтинг: 0 / 0
31.10.2006, 21:56:17
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095896
он же
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
он же
Участник
Kachalov
...
Рейтинг: 0 / 0
31.10.2006, 22:24:32
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095901
он же
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
он же
Участник
А я так хорошо пил пиво...
См. аттач.


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
C:\Program Files\Java\jdk1. 5 .0_07\bin>javac FileProcessor.java 

C:\Program Files\Java\jdk1. 5 .0_07\bin>java FileProcessor w 
Wrote  250000   470 -bytes records in  3359  msec

C:\Program Files\Java\jdk1. 5 .0_07\bin>java FileProcessor r 
Proceed  117500000  bytes records in  4032  msec with  2500000  failures
...
Рейтинг: 0 / 0
31.10.2006, 22:28:45
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095903
он же
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
он же
Участник
Доводку напильником оставляю на совести того, кому этот пример пригодится :)
А доводка нужна. Начиная с обработки EOFException и заканчивая оптимальным выбором MULT.

Я ответил на вопрос
Kachalov он жечитать не линейно, а блоками :)
- а блоками читать как? по очереди?
? :)
...
Рейтинг: 0 / 0
31.10.2006, 22:32:45
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34095976
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
он жеЯ ответил на вопрос
Kachalov он жечитать не линейно, а блоками :)
- а блоками читать как? по очереди?
? :)
- выходит читаете по очереди блоками, т. е. линейное чтение, если то же самое сделате с буферизованым потоком, результаты по быстродействию будут те же самые, а код получится проще. Представленное решение иллюстрирует как можно с помощью класса RandomAccessFile создать аналог буферизованого чтения :(

P. S. не обязательно было писать этот код, основы программирования на Java многим знакомы :)
...
Рейтинг: 0 / 0
01.11.2006, 00:14:20
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34096019
LINUXER
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LINUXER
Участник
Согласен что RandomAccessFile врятли поможет
Есть мудрые алгоритмы типа КМП(Кнута — Морриса — Пратта)
Врятли захочется с ними возиться, но если выигрыш в скорости действительно нужен ..
...
Рейтинг: 0 / 0
01.11.2006, 03:37:27
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34096256
он же
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
он же
Участник
Kachalov
- выходит читаете по очереди блоками, т. е. линейное чтение, если то же самое сделате с буферизованым потоком, результаты по быстродействию будут те же самые, а код получится проще. Представленное решение иллюстрирует как можно с помощью класса RandomAccessFile создать аналог буферизованого чтения :(

P. S. не обязательно было писать этот код, основы программирования на Java многим знакомы :)
Боюсь, основы плохо знакомы.
Иначе вы не говорили бы, что 3.5 сек (моё решение) и 5.8 сек (BufferedReader) - это одинаковая скорость. И это в случае уже закэшированного виндой файлика.
Если обрабатываем с чтением, то цифры:
Proceed 290374304 bytes records in 11031 msec with 6178176 failures
Proceed 287888895 buffered bytes in 26422 msec with 2537871 failures
Только тут не совсем честно, т.к. файлы совершенно произвольные.
А может вы хотите чтобы всё парсилось еще в 5 раз быстрее? Тогда с Java нужно уходить с сторону плюсов.


Код, как я понял, приводить не нужно.
...
Рейтинг: 0 / 0
01.11.2006, 09:37:32
| Ответить | Цитировать | Написать  
быстрый поиск в файле
    #34097649
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
2 Гость111, он же

Я - бы предложил упростить постановку.

1) Давайте считать, что мы ищем в структурированом бинарном файле (размер структуры = 47 байт) подстроку байтов в поле типа byte[9] по смещению 0 от начала структуры.

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

Искомую строку можно заранее сконвертировать в байтовый массив.

Условно считаем, что байт = символ в коде ASCII.

2) Подозреваю, что следующие операции в теле цикла
Код: plaintext
1.
2.
3.
byte tempArray[] = new byte[SEARCHABLESIZE];
System.arraycopy(array10, i * SIZE, tempArray,  0 , SEARCHABLESIZE);
String xString = new String(tempArray).trim();
избыточны, и без них можно вполне обойтись.

3) Меня удивляет что CurrentTimeMillis() выдает (в Windows) сильно "загрублённое" время. И время работы процеса (разность между снапшотами) я вижу - как константу. Это настораживает. Поэтому в качестве функции снапшота времени предлагаю использовать не CurrentTimeMillis(), а nanoTime()/1000000. Она более точна ИМХО.

С уваженим.
...
Рейтинг: 0 / 0
01.11.2006, 14:31:15
| Ответить | Цитировать | Написать  
25 сообщений из 38, страница 1 из 2
  1  все
Форумы / Java [игнор отключен] [закрыт для гостей] / быстрый поиск в файле
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&fpage=645&tid=2145998]:
 0ms
get settings:
 13ms
get forum list:
 20ms
check forum access:
 5ms
check topic access:
 5ms
track hit:
 41ms
get topic data:
 19ms
get forum data:
 3ms
get page messages:
 80ms
get tp. blocked users:
 3ms
others: 273ms
total:  462ms
созд. / загр.: 462ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]