|
|
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Добрый день! Какой самый быстрый способ чтения файла в java ? Использовал самый простой построчный подход : Файл вида : строки разделенные \t табом. name1\tname2\tname3\tname4\tname5 name6\tname7\tname8\tname9\tname10 .... namen\tnamez\tnamex\tnamek\tnamep ( на файле в 1 млн строк ) BufferedReader - тратит 2 секунды (чисто на чтение ) это очень долго. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 11:46 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Попробуй размер буфера побольше указать. Для больших файлов может помочь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 11:48 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, особой разницы нет , если увеличить буфер в 4 раза - работает медленнее в 2 раза ... нашел только это : самый быстрый способ чтения в java: Код: java 1. 2. 3. 4. 5. 6. 7. 8. но это не для строк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 12:00 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1 особой разницы нет , если увеличить буфер в 4 раза - работает медленнее в 2 раза ... И это точно никак не связано с readLine? Т.е. мерял исключительно IO? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 12:11 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1 Файлы состоят из байт, а не строк... Это намёк на то, что можно исключить операцию разбора буфера на строки, заполнять ArrayList<String> по мере парсинга данных, по нахождению символов перевода строки "укладывать" ArrayList в связанный список. тогда избавитесь от накладок по памяти и времени связанных с двойным проходом по буферу. Т.е. всё должно происходить в один проход... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:51 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
за сколько времени этот же файл копируется в /dev/null? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:44 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
chabapokза сколько времени этот же файл копируется в /dev/null?Это зависит от того чем и как копируют... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 15:22 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Alex KuznetsovЭто зависит от того чем и как копируют...Если файл не разреженный и чтение не посимвольное, то все прочие различия сильно нивелируются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 16:05 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Делали замеры - по разным языкам , платформам и средам java показывает один из самых плохих результатов :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 16:27 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1Делали замеры - по разным языкам , платформам и средам java показывает один из самых плохих результатов :( Что с одной стороны - не удивительно (все же JRE частично интерпретатор), с другой стороны - при наличие желания , разница в скорости должна быть достаточно не большая и в большей мере лимитироваться скоростью чтения с диска (JIT) Да и вообще, задача считать много миллионно строковый файл с максимальной скоростью - выглядит немного странно. Если его нужно считывать все время - нафига? почему такой не удобный формат? если при загрузки приложения - то +/- пара секунд большого значения иметь не должно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 17:31 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1, Код: java 1. 2. 3. 4. 5. 1000000 строк - 1000000 раз будет создаваться и компилироваться Pattern, скорее всего, можно ускорить разбор, заготовив Pattern заранее. Еще быстрее - искать индекс символа '\t' с помощью метода String.indexOf(ch, fromIndex), чтобы не городить паттерн из-за одного символа. Ну и с доступом к файлу, меппинг в память (MappedByteBuffer) - правильное направление, это действительно самый быстрый способ, так сказать, буферизация средствами ОС, но со строками придется повозиться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 18:08 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Проверил на JDK 7 c nio Для простоты заменил ArrayList<String> на Bill (простой класс с полями под строку name1\tname2\tname3\tname4\tname5) Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. время 2.7 секунды При переходе на JDK 8 стабильно +1 секунда и время хуже чем в JDK 6 (порядка 3 секунд). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 18:12 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Если нужна скорость: 1. Если чтение информации многократное, хранить в нормальном формате. Не текстовый, а нормальный двоичный формат 2. Нафиг ООП 3. Нормально профилировать приложение, а не мерить диаметр сферического коня (subj) в вакууме. Куда у Вас уходит время, только Вам и известно: толи ввод/вывод, толи выделение памяти под не нужное ООП, толи GC, толи в LinkedList. etc... IMHO & AFAIK Ради интереса: 1. сколько полей в одной строке файла 2. какой размер файла в байтах 3. какой размер отдельных полей Только сейчас написал простенький тест на Java. Если не заниматься фигней (типа универсальным преобразованием из любой кодовой таблицы в/из UTF8, ООП и прочее) скорость Java не настолько уж и плохая ))) по крайней мере на моем рабочем компе ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:22 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1, в идеальном варианте ты делаешь 2 потока. 1-й читает блоками char[] и пишет в кольцевую память. 2-й поток - конечный автомат (Finite-state_machine) который разбирает эти блоки и генерирует евенты. Например - 'onBeginBackslashSymbol'. И соотв. принимает какие-то решения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:22 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Mayton, там еще на преобразование charset время уходит дофига. Скорее всего. А с учетом много-символьных MBCS задача организовать кольцевой буфер будет не сильно простая. Лично я бы упрощал задачу. Нафиг все много-символьные MBCS. IMHO. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:25 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
На моем компе только чтение из файла размером 163 Mb: read binary - 54 ms. (ручками) read text - 3906 ms. (через java.io.Reader) При ограничении charset'ов только однобайтовыми наборами, легко можно читать и парсить в несколько потоков. Но при многобайтовых MBCS, задача скорее всего усложнится IMHO & AFAIK. Как минимум нужно книжки читать (я не настолько хорошо знаю принципы организации многобайтовых MBCS) и реализацию Charset и Reader смотреть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:30 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevMayton, там еще на преобразование charset время уходит дофига. Скорее всего. Вот это коментарий в точку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:34 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, потесть пожалуйста utf-8, utf-16, и однобайтовые. Я думаю что utf-8 должен иметь самый хардкорный char-decoder. Фактически дезархиватор мать его так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:35 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Проблема не в хардкордном. А то, что все интерфейсы сделаны универсальными и ООП'ыми. Соответственно, Charset при декодировании вынужден порождать кучу вспомогательных буферов и отслеживать движение вперед/назад по потоку. IMHO & AFAIK Думаю, разницы в скорости реализации стандартных декодеров Charset большой нет. Даже тестить не охота. Проблема не в конкретном charset, а в _универсальности_ стандартных реализаций. Если же ОГРАНИЧИВАТЬ исходную задачу, то тогда можно сделать быстрое решение. Если же делать УНИВЕРСАЛЬНОЕ решение, то нефиг на Java поклеп возводить. Плата за универсальность и поддержку кучи Charset. Но судя по постам автора - а оно на форуме надо? решать дебильную по постановке задачу и заниматься оптимизацией. В принципе, такая работа как оптимизация бизнес-критикал кусков кода IMHO & AFAIK очень дорого стоит. К тому же, совершенно не понятно. ЗАЧЕМ это нужно. Один раз считать файл при загрузки приложение, что 0.5 сек, что 5 сек - роли большой иметь не должно. Нужна сверх скорость (близкая к ассемблеру) - перерабатывать постановку, делать нормальные форматы хранения данных и на диске и в памяти. Загонять миллионы объектов в LinkedList лично мне Java'у было бы жалко ))) Но я программировать учился на 286 с 1 Mb ОП и там ГИС писал (ГеоИнформационная система), т.ч. уже при словах LinkedList, миллион объектов мне компьютер и процессор жалко становится. Жалостливый я очень ))). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:48 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сишники хардкодили char как byte. Это в 99% случаев решало проблемы перекодировок. И парсеры работали с байтами. Но эпоха 1-byte ушла. А Unicode так и не зохватила вселенную. Вот и сидим на двух стульях. Внутри БД Oracle до сих пор рулит 1251 ибо быстро и нефих. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 20:08 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
maytonСишники хардкодили char как byte. Это в 99% случаев решало проблемы перекодировок. И парсеры работали с байтами. Но эпоха 1-byte ушла. А Unicode так и не зохватила вселенную. Вот и сидим на двух стульях. Внутри БД Oracle до сих пор рулит 1251 ибо быстро и нефих.Вот и я о том, нефиг заниматься мазохизмом пытаясь выжать из тройного разбора строк скорость. Хоть все соки выжми - нифига хорошего не выйдет. Проход по файлу и по считанному буферу должен быть всего один. И именно за один проход нужно строить весь список, а не херячить по буферу в поисках строк с помощью ReadLn, затем выпендриваться с вызовом split, наконец всё это зафигачивать в ArrayList и только потом этот ArrayList запендюривать в LinkedList... Файл должен рассматриваться как набор байт с двумя типами разделителей и фсё... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 21:05 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
У меня. Файл миллион строк, 50 колонок, размер 421 Mb Изначальная автора: от 2 259 до 5 807 ms Моя реализация - от 13 262 до 14 849 ms Моя реализация, парсинг плюс перегон в String[] (без построения LinkedList) - 3 444 Моя реализация, чтение файла + конвертация charset + парсинг онли - 1 575 Моя реализация, чтение файла + конвертация charset only - 228 ms ((( Почему кусок кода построения LinkedList, вставленный без изменения в мой алгоритм, настолько резко начинает тормозит. Мне не понятно. Шаманство. Код: java 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 22:05 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, запускай профилировщик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 22:11 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsevтам еще на преобразование charset время уходит дофига. Скорее всего. Да не особо. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Генератор Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. ReadFile.java Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 22:12 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevУ меня. Файл миллион строк, 50 колонок, размер 421 Mb Изначальная автора: от 2 259 до 5 807 ms Моя реализация - от 13 262 до 14 849 ms Моя реализация, парсинг плюс перегон в String[] (без построения LinkedList) - 3 444 Моя реализация, чтение файла + конвертация charset + парсинг онли - 1 575 Моя реализация, чтение файла + конвертация charset only - 228 ms ((( Почему кусок кода построения LinkedList, вставленный без изменения в мой алгоритм, настолько резко начинает тормозит. Мне не понятно. Шаманство. Код: java 1. 2. 3. На этом месте у меня так же наблюдается сильное падение - фактически 50% от общего времени ! Первое что приходит - большие накладные расходы - на ArrayList - и LinkedList пытался их оптимизировать - ставя размеры итд ... видимо нужно отказываться от такого формата . переходить на простые массивы или читать как описали -в буфер а уже его парсить. Давайте выкинем ArrayList и LinkedList и просто разберемся с чтение файла по строкам! Да за ООП - приходиться много платить и за весь стек интерфейсов и абстракций и всему должно быть объяснение , но не в секунды , когда тот же awk - делает эту же задачу на порядок быстрее! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 22:34 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38562794&tid=2123129]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
77ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
72ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 438ms |

| 0 / 0 |
