|
|
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#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 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, К тому же, совершенно не понятно. ЗАЧЕМ это нужно. Один раз считать файл при загрузки приложение, что 0.5 сек, что 5 сек - роли большой иметь не должно. Нужна сверх скорость (близкая к ассемблеру) - перерабатывать постановку, делать нормальные форматы хранения данных и на диске и в памяти. Загонять миллионы объектов в LinkedList лично мне Java'у было бы жалко ))) Но я программировать учился на 286 с 1 Mb ОП и там ГИС писал (ГеоИнформационная система), т.ч. уже при словах LinkedList, миллион объектов мне компьютер и процессор жалко становится. Жалостливый я очень ))). Скажем так - всегда считал что это быстро , когда писал такой код - и не задумывался о том 0.5 или 5 сек. но когда решил проверить как такое же будет проходить в С++ или через простой awk - понял насколько медленно это делает JAVA ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 22:40 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Исходные данные: лям строк, 50 колонок, 421 Mb файл В общем, сильно зависит от heap'а. В пред. замерах при копи пасте кода автора ошибся, парсинг не шел. На СОВЕРШЕННО ПУСТОМ heap'е. Мой алгоритм 7 316 - 13 328 ms Старая реализация 7 174 - 10 077 ms На ЗАМУСОРЕННОМ heap'е. (результата предыдущего чтения файла остаются в памяти). Мой алгоритм 15 181 - 19 079 ms Старая реализация 18 856 - 19 914 ms Что и понятно ))) По результатам есть чувство: 1. что String.split написан на native коде. 2. Работа JIT компилятора штука совершенно не предсказуемая ((( Добавление вызова пустого метода внутрь цикла - резко портит скорость. 3. Разворачивания методов в inline JIT компилятор делает крайне странно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 22:42 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Насколько я помню по C++: все listы - бяки, деревья - еще большие бяки. Array'и намного лучше. Компактнее лежат в памяти, при больших объемах значительный выигрыш по памяти и соответственно по производительности. Такие задачи, обработка большого массива информации - сильно зависят от загаженности системы и настройки подсистемы памяти. IMHO (на истину не претендую): Если eden достаточный, то лишние объекты и копирование туда-сюда сильно больших проблем создавать не должно. А вот old-gen heap работает значительно медленнее. Для системы, если действительно нужно держать миллионы строк в памяти - я бы пытался хранить наиболее компактно. Java для этого, к сожалению, не самый лучший инструмент. ООП однако. Ну и задача мне СОВЕРШЕННО НЕ ПОНЯТНА? Почему, если обработка данных настолько критична, ТЕКСТОВЫЙ файл? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 22:50 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevНу и задача мне СОВЕРШЕННО НЕ ПОНЯТНА? Почему, если обработка данных настолько критична, ТЕКСТОВЫЙ файл?Да всякое бывает. Почитайте, например, чем занимается компания Splunk. У них как раз джавовский продукт, который должен максимально быстро перелопачивать именно текстовые данные. Ничего в этом странного нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 23:03 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev Ну и задача мне СОВЕРШЕННО НЕ ПОНЯТНА? Почему, если обработка данных настолько критична, ТЕКСТОВЫЙ файл? Прилетел вам от клиента файл такого формата , строки с какой-то инфой разделенные табами... Ну удобно им в файл писать - в виде имя \t номер телефона \t дата \t почта \t адрес итд... и просят вас что то посчитать в этом файле - что то найти ... ну вот мне и интересно стало - показалось что медленно читает по строкам ... и действительно проверил : оставил только счетчик Код: java 1. 2. 3. 4. 5. 6. и аналогичный код на с++ через fopen и увидел что это в разы быстрее ... вот и задумался ... (Хотя к слову сказать - в C++ можно получить результаты отличающиеся в 2 раза - только используя более свежую версию компилятора, но в любом случае на порядок быстрее чем в java) чудеса. поэтому и решил спросить - так ли это ? может кто знает почему так медленно ? где тут потери? в чем ? на будущее чтобы знать ? и чтобы лучше понимать этот волшебный мир java ! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 23:09 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Всем спасибо! ответы тут : http://nadeausoftware.com/articles/2008/02/java_tip_how_read_files_quickly ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 23:29 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1но когда решил проверить как такое же будет проходить в С++ или через простой awk - понял насколько медленно это делает JAVAAtum1и аналогичный код на с++ через fopen и увидел что это в разы быстрее ... Показывай полный код на java и полный аналогичный код на c++. P.S. Arrays.asList и так возвращает (фактически) ArrayList незачем здесь создавать ещё один ArrayList (и копировать в него все элементы..), readLine, split и LinkedList тоже плохие слова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 07:56 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczПопробуй размер буфера побольше указать. Для больших файлов может помочь. В данном случае, для правильной оптимизации, ещё необходимо подобрать размер буфера кратный размеру строки в файле. При "неправильном" размере буфера эффект может оказаться отрицательным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 10:30 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
avp.mkПоказывай полный код на java и полный аналогичный код на c++. исходный файл на 1 млн строк вида ( размер порядка 65 Мб) : авторname date phone email cost Имя1 16.04.2014 07:16:15 79294595328 vrghjm0@gmail.com 110 Имя2 19.05.2014 06:48:26 79933782391 p25ghjgt1@ya.ru 23 имя2 08.06.2014 05:40:37 79812440379 h7ghgfh48@list.ru 15 ... JAVA лучшее время read file 899 ms Код: java 1. 2. 3. 4. 5. 6. 7. С++ 139 ms , компилятор gcc 4.7.2, ядро 3.2.0-4, debian 7, Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz total heap usage:1,000,023 allocs, 1,000,023 frees, 86,061,056 bytes allocated Код: plaintext 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. (Тут есть один нюанс - если читать в с++ файл построчно - не в массив ,то время будет в два раза лучше , чуть больше 65 ms) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 10:49 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1 JAVA лучшее время read file 899 ms Код: java 1. 2. 3. 4. 5. 6. 7. Оформите в виде jmh бенча, иначе цифры ни о чем не говорят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 11:21 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
just_vladimirОформите в виде jmh бенча, иначе цифры ни о чем не говорят. тут все расписано ! http://nadeausoftware.com/articles/2008/02/java_tip_how_read_files_quickly с 2008 года особо ничего не изменилось. Тему можно закрыть ! Всем спасибо за помощь и участие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 11:26 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1Leonid KudryavtsevНу и задача мне СОВЕРШЕННО НЕ ПОНЯТНА? Почему, если обработка данных настолько критична, ТЕКСТОВЫЙ файл? Прилетел вам от клиента файл такого формата , строки с какой-то инфой разделенные табами... В чем принципиальный смысл требования "2-е секунды" ? Прилетел файл - обработали. 2 или 5 секунд думаю для оператора большой роли не играет. Если обработка на сервере и файлы летают туда-сюда... важна не абсолютная скорость, а возможность масштабирования решения, например возможность выполняться много-потокова на туевой куче процессоров... тут за Java Вы заплатите скоростью, но выиграете в простоте и отказоустойчивости (меньше багов) результирующего кода + поддержка со стороны application server'ов, плюс поддержка кодировок, плюс куча других плюшек Atum1Ну удобно им в файл писать - в виде имя \t номер телефона \t дата \t почта \t адрес итд... и просят вас что то посчитать в этом файле - что то найти ... Ну и нафига для того, что бы что-то подсчитать весь многомиллионный файл загонять в память. Пройтись, разпарсить, подсчитать. Тут Java и любое другое ООП-решение конечно будет резко проигрывать, просто за счет туевой кучи лишнего кода на абстракциях. Без ООП - банальный конечный автомат и почти нулевые требования по памяти (только буффер для чтения файла), при ООП - классы и создание объектов. При ООП подходе: Java обычно работает с память крайне быстро. Создание объектов в Java значительно БЫСТРЕЕ, чем в C++. Но и последующие проблемы с GC. Но здесь нужно память под приложение (не алгоритм, а приложение) настраивать. В продакшен системе крупного биллинга, после нормальной настройки eden области, у нас Full GC стал запускаться 2-а раза в сутки, вместо раз в 5-10 секунд. Но это нужно запускать JRE с нормальными настройками под задачу. AFAIK (выделение памяти замерял несколько лет назад, сейчас создавать тесты лениво). Задача создать в памяти 50 миллионов объектов, что бы было - совсем не понятна. Нафига? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 13:04 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Если метод подхватывается JIT-компилиром, время должно быть сравнимо. Если метод НЕ подхватывается JIT-компилиром, Java резко тормознутее. Что и понятно. Интерпретатор байт-кода. Куча и потери на GC. При миллионах строк и миллионах объектов - отнюдь не бесплатно. IMHO & AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 13:06 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1Leonid KudryavtsevНу и задача мне СОВЕРШЕННО НЕ ПОНЯТНА? Почему, если обработка данных настолько критична, ТЕКСТОВЫЙ файл? Прилетел вам от клиента файл такого формата , строки с какой-то инфой разделенные табами... Ну удобно им в файл писать - в виде имя \t номер телефона \t дата \t почта \t адрес итд... и просят вас что то посчитать в этом файле - что то найти ... ну вот мне и интересно стало - показалось что медленно читает по строкам ... Постановка немного абсурдна. Если вам "прилетел" файл - то пускай улетает обратно. В продуктиве нет таких постановок. В противном случае если "очень нуна" и срочно - бородатый unix-сисадмин возьмёт grep/sed/awk/find и найдет вам всё что нужно за приемлемое время. Если мощи утилит не хватит - то напишет на perl-е парсер. Всяко это будет быстрее чем делать в Java (Java проект - очень дорого стоит если стартовать его с нуля для подобных Превед-Медвед-миров). Кстати это (perl) должно быть отправной точкой при бенчмарках. В противном случае можно еще и усомниться в целесообразности Java вообще в подобной задаче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 13:38 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Я бы еще сказал, что еще крайне большая проблема - измерение производительности. Мною написанный парсер явно на JIT-компиляторе не компилировался. С учетом появившегося в 1.5 (не знал) class-data-sharing, любая сферическая реализация на стандартных классах в вакууме должна быть быстрее В продакшене, при загруженной системе и включившимся JIT-компиляторе, самопалный парсер должен ООП уделывать /надеюсь ))) / Плюс мониторинг/настройка JVM: память (раз в нее закачиваются больше объемы), JIT. ==== Задача поставлена сферически. Загнать файл (неизвестного объема!!!) в дебильную структуру в памяти. При дебильном формате файла (текст, х.з. что с кодировками, в задаче не уточнено). Нужна скорость, тогда в первую очередь: 1. Нормальный алгортм (для описанной задачи: пройтись один раз по файлу, разпарсить и обработать, сохранять в памяти и никакие LinkedList'ы даром не нужны). 2. Нормальные форматы хранения в памяти и на диске 3. Нормальная постановка, упрощение задачи. Универсальность решения VS самопал. Не универсально, но быстро. IMHO & AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 14:03 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Коллеги выкинтье из головы вообще все Arrays, Lists и вообще коллекции! У вас любая задача почему-то вырождается в Стебелёк! Занахрена вам вообще в памяти Java нужны эти гигбайтные списки и массивы? Что с ними дальше будете делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 14:08 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
LinkedList тут действительно не в тему - фичи, на которых он имеет преимущество (вставка и удаление в середине списка), по крайней мере, в приведенном коде, не используются. А вставка в конец и у ArrayList достаточно оптимально сделана, тем более, что можно сразу место зарезервировать, ориентируясь на размеры файла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 14:10 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Для примера, создание и вставка 50 000 000 строк в LinkedList<String> и ArrayList<String>. На чистой 64 бит JVM. Наиболее показательны следующие вещи: 1. ОБЪЕМ который весь этот мусор занимает в памяти 2. Разница в объеме (компактность хранения) LinkedList vs ArrayList (> 20%) 3. Разница в скорости, при дефолтных параметрах JVM и запуск JVM с изначально выделенной памятью (!!!). Разница в скорость еще больше впечатляет, если смотреть на Task Manager ))), при дефолтных параметрах все мои 8 ядер под 100% заняты ))) Тестировал лет 10 назад, на ООП задачах (наплодить много объектов))) ), Java уделывает C++ ! Если бы C++ пример с парсингом в коллекцию был не такой сферический, не факт, что Java не вырвалась бы в отрыв AFAIK >java.exe -server -classpath .\classes test.CreateArray CreateArray time= 34488 totalMemory=6603407360 freeMemory=2434775960 usedMemory=4168631400 >java.exe -server -classpath .\classes -Xms8000m -Xmx8000m test.CreateArray CreateArray time= 6532 totalMemory=6873939968 freeMemory=2705308568 usedMemory=4168631400 >java.exe -server -classpath .\classes test.CreateList CreateList time=44889 totalMemory=7319060480 freeMemory=2230793400 usedMemory=5088267080 >java.exe -server -classpath .\classes -Xms8000m -Xmx8000m test.CreateList CreateList time=11226 totalMemory=6873939968 freeMemory=1785672888 usedMemory=5088267080 >java.exe -server -classpath .\classes -Xms12000m -Xmx12000m test.CreateList CreateList time=10848 totalMemory=12058624000 freeMemory=6970356920 usedMemory=5088267080 Кроме создания коллекции, еще и создаются 50 000 0000 строк через StringBuilder парой вложенных методов. Т.ч. в процессе создается и удаляется > 300 000 0000 StringBuilder'ов и куча промежуточных String. Записанные в файл, те же данные занимают "всего" 844 Mb /far/. Т.ч. осмысленность тащить для обработки большой объем данных в память - нет никакого. Потери (в том числе и времени) на хранения в виде "рыхлых" объектов, может быть больше, чем создания временных объектов в динамике. (Java ОЧЕНЬ быстро создает объекты, если JVM и GC работает в комфортном режиме). IMHO & AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 14:37 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
А дальше-то что с данными происходит? Если только просмотр-анализ можно же просто прочитать весь файл одной длинной строкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 16:08 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1avp.mkПоказывай полный код на java и полный аналогичный код на c++. исходный файл на 1 млн строк вида ( размер порядка 65 Мб) : авторname date phone email cost Имя1 16.04.2014 07:16:15 79294595328 vrghjm0@gmail.com 110 Имя2 19.05.2014 06:48:26 79933782391 p25ghjgt1@ya.ru 23 имя2 08.06.2014 05:40:37 79812440379 h7ghgfh48@list.ru 15 ... JAVA лучшее время read file 899 ms Код: java 1. 2. 3. 4. 5. 6. 7. С++ 139 ms , компилятор gcc 4.7.2, ядро 3.2.0-4, debian 7, Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz total heap usage:1,000,023 allocs, 1,000,023 frees, 86,061,056 bytes allocated Код: plaintext 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. (Тут есть один нюанс - если читать в с++ файл построчно - не в массив ,то время будет в два раза лучше , чуть больше 65 ms) Я может чего то не понимаю, как bufferedreader может быть быстрее filechannel? Вы не ошиблись? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 16:10 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
ОзверинЯ может чего то не понимаю, как bufferedreader может быть быстрее filechannel? Вы не ошиблись? filechannel быстрее bufferedreader . (кажется по ссылке что я указал это как раз и описано ) а можно увидеть код построчного чтения файла? можно ли читать файл исключительно по следовательно по одной строке? (может быть через randomaccessfile) сразу обрабатывая текущую строку и переходя на след. не создавая буферов, массивов строк , коллекций итд ... будет ли это быстрее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 22:28 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1а можно увидеть код построчного чтения файла? Ничего интересного. ReadLine использует посимвольное чтение из буфера символов char[] cb в цикле и накапливает строку в StringBuffer. Кстати это яркий пример реализации конечного автомата. У него есть состояния. http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/io/BufferedReader.java#BufferedReader.readLine(boolean) можно ли читать файл исключительно по следовательно по одной строке? (может быть через randomaccessfile) сразу обрабатывая текущую строку и переходя на след. не создавая буферов, массивов строк , коллекций итд ... будет ли это быстрее? Можно. Но при этом мы теряем возможность работать с канальными устройствами (stdin, pipes e.t.c) т.к. "режим открывания" файла становится более жёстким. Думаю что быстрее не будет. Вообще дисковый интерфейс спроектирован так что на любой чих HDD читает или пишет сектор (512 байт) или более крупный блок информации в зависимости от типа устройства. Поэтому чтение избирательными порциями - безсмысленно. Оно не приводит к особому убыстрению. Для вычитки строк можно просто вычитать "на будущее" char[] буфер поболее и работать с ним как в BufferedReader. Вычитывание по символам или по байтам - это просто софтварная надстройка на уровне OS API. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 23:01 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Самое интересное, что попытка в своем классе сделать простейший конечный автомат дает ужасную производительность. При этом все стопориться на if... или на switch.... Добавление даже одного if в код, тут же посимвольную обработку _резко_ замедляет ((( Теоретически, вроде все понятно. Практически, за 2-а дня я на самодельном конечном автомате только достиг скорости исходного алгоритма (правда при _значительно_ меньшем потребности к выделению на куче и к GC) при значительно большей простоте алгоритма (минус все преобразование символов, никаких StringBuilder'ов). В общем JIT-компилятор штука загодочная. Несмотря на то, что -XX:+PrintCompilation и -XX:+PrintInlining уверяют, что весь код откомпилирован. Рантайм библиотеки работают быстрее (или так же) самопального конечного автомата. Хотя... это теоретически... практически задача ИМХУ - сферический конь в вакууме. Чем скорость решения со split автора не устраивает - не понятно. Хотя, у него скорее всего вообще все на GC может стоять колом. У меня за 1.8-2 сек файл в 844 Mb парсится (без сохранения в LinkedList, только до String[]) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.02.2014, 23:35 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Думаю что здесь уже нельзя достичь больше производительности по той простой причине что мы играем по правилам реализации java.lang.String. Можно было-бы читать byte[] договорившись что рассматриваем single-byte encoded file но на выхлопе не сможем получить String. Или сможем но опять будет трансформация кодировки со всеми накладными расходами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 00:01 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
maytonДумаю что здесь уже нельзя достичь больше производительности по той простой причине что мы играем по правилам реализации java.lang.String. Можно было-бы читать byte[] договорившись что рассматриваем single-byte encoded file но на выхлопе не сможем получить String. Или сможем но опять будет трансформация кодировки со всеми накладными расходами.Без понимания того, в какой кодировке приходит файл, как он затем должен быть обработан и что впоследствии должно получиться, действительно можно гадать о том как улучшить производительность. Вполне может статься, что данные приходят в Win1251 кодировке, поэтому просто byte[] чтение с приведением к char[] вполне может решить исходную задачу. Но это как говорится только автору известно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 07:22 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Не, все хуже. String'и и все остальное работает крайне быстро. Тут все упирается в JIT-компилятор. А вот как он код оптимизирует - ведает только он. Тот конечный автомат, который написал я, банально стоит колом на IF...'а и SWITCH'е (для определения что пришло во входном потоке \t,\n,\r или просто символ). От перестановки IF..ELSE местами, скорость меняется в разы. Только не понятно, толи я уже наткнулся на предел работы процессора (промахи предсказания перехода, промахи кеша), толи приколы JIT компилятора. Толи все вместе. Но как стандартный код умудряется давать ту же скорость - мне не понятно, но честно говоря, практического интереса для меня не представляет. Хотя, возможно, я где-то с замерами ошибся . У меня файл 844 Mb (лям строк, 50 полей) предельные цифры: чтения с диска 700 ms (844/0.7=1205 Mb/s, явно из кэша ОС читает), 1251 -> char = 100 ms, и парсинг + конструирования string[] от 1.1 до 3 сек. Если переписать 10 строк Java на Native код, будет быстрее. Но сейчас 30% времени - тупо чтение файла (нативные методы JRE), 60% обработка. Т.е. Java -> Native C даст выигрыш на _всей_ задачи парсинга не более в 3 раза. С учетом последующей обработки (зачем-то же файл читается) - еще меньше. Оно того нужно? По совокупности, а не ради спортивного интереса. Ради спортивного интереса можно и на асме под проц. затачивать (смотреть в Intel Vtune и промахи оптимизировать) или много-потоковую обработку файла (как в Oracle ))) parallel full table scan и etc ))) ) сделать. Да на кластер! Вот где скорость будет! Если автор оплатит - можно и запилить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 12:44 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevЕсли переписать 10 строк Java на Native код, будет быстрее. Но сейчас 30% времени - тупо чтение файла (нативные методы JRE), 60% обработка. Т.е. Java -> Native C даст выигрыш на _всей_ задачи парсинга не более в 3 раза. Думаю что не будет быстрее. У вас будут накладные расходы на JNDI callbacks в случае если вы должны всё равно переходить в контекст Java-кода. Если мы говорим о С++ - то это оффтопик и отдельный вопрос в отдельный форум. В целом I/O (since 6) Java IO (NIO) достаточно хорошо написан чтобы вообще не думать о явном использовании средств ОС. Если у автора стоит задача - прогрузить это всё в БД (bulk load/bulk insert) то надо сначала выкурить всякие утилитки от вендора БД, собрать на их базе макет или скриптик, потестировать а уж после этого делать свой bulk-велосипед. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 12:53 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
JNI тоесть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 12:53 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
В общем, запустить ИСХОДНЫЙ C++ и Java код на своем компьютере со своим примером файла 885 Mb. C++ (откомпилировано в Debug mode /без оптимизации/, вызов gettimeofday заменен на timeGetTime): потребление памяти по Task Manager из Windows 921 584 Mb parsing + create collection = 9100 free memory = 977 C++ (откомпилировано в Release): parsing + create collection = 3457 free memory = 160 Java, старый алгоритм автора, но сохраняет все данные в ArrayList<String[]> (Ну не люблю я списки и деревья! Старая, десятилетняя ненависть!). Настройки JVM -Xms8000m -Xmx8000m ParserOld time=2823 Total Garbage Collections: 1 Total Garbage Collection Time (ms): 480 arr.size=1000000 totalMemory=8039104512 freeMemory=6197443160 usedMemory=1841661352 ----- Total Garbage Collections: 5 Total Garbage Collection Time (ms): 1369 totalMemory=8039104512 freeMemory=8038830432 usedMemory=274080 total time=3715 Отсюда вопрос: и где Java медленнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 13:34 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Леонид! На что мы должны смотреть? Здесь ничего нет. Нет кода который можно было-бы комментировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 13:41 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сравнение i/o на java и на c/c++ в основном это замеры оверхеда от выделения памяти виртуальной машиной т.к. все массивы байт скопируются по N-раз пока дойдут до места, где java-разработчик может ими начать оперировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 13:44 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
maytonДумаю что не будет быстрее.... Будет, будет... ))) JNDI вряд ли сильно большие накладные расходы дает, оно же в одном окружении. Зато на C и ASM'е можно с предсказателем переходов поиграться ))) и правильный порядок If...else... поставить ))) В общем, пока моя имплементация конечного автомата медленнее исходной реализации автора на стандартных Java функция (((. Правда зато память используется намного меньше! А память это лишняя работа GC, при многопотоковости/многопользователях это может быть важнее, чем пиковая скорость. Вообще, тема интересная. Много нового о Java узнал. Только расстраивает, что JIT-компилятор совершенно черный ящик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 13:45 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, при чём здесь вообще Си и Ассемблер? При чём здесь вообще if-else ? Это всё вопросы не в тему топика. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 13:52 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
А чего коментировать? Исходная задача автором не описана. Исходного файла от автора нет. То, что Java ЗНАЧИТЕЛЬНО медленнее C++, он НЕ прав. Исходной код автора 15580799 C++[/msg] и 15576134 Java[/msg], работает лично на моей машине одинаковое/сравнимое время. Если -Xms8000m -Xmx8000m выставить ))). При этом, замеры скорость явно выше скорости чтения с физических дисков /даже мой SSD такой скорости давать не должен/. Т.ч. мерится сферический конь в вакууме. На реальной задаче , Subj смысла не имеет. Мне профит: прочитал кучу статей о JIT-компиляторе и узнал кое-что новое по синтаксису Java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 14:02 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
maytonLeonid Kudryavtsev, при чём здесь вообще Си и Ассемблер? При чём здесь вообще if-else ? Это всё вопросы не в тему топика. Притом, что скорость исходного кода автора, при нормальной настройке окружения Java - похоже приближается к пределу железа. Выделение памяти/объектов, для Java операция почти "бесплатная" (если в eden) Если хочется быстрее "парсить" (проверять пришедший символ на \r, \n) - то тогда только оптимизация под проц (промахи переходов, кеша и т.д.) ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 14:18 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Я напоминаю что мы находимся в форуме Java и автору, скорее всего будут неинтересны решения на pure C/C++/Assembler. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 15:14 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1ОзверинЯ может чего то не понимаю, как bufferedreader может быть быстрее filechannel? Вы не ошиблись? filechannel быстрее bufferedreader . (кажется по ссылке что я указал это как раз и описано ) но именно ваш код используется Files.readAll или что то типа того, которая является оберктой для bufferedreader`а.?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.02.2014, 22:00 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1исходный файл на 1 млн строк вида ( размер порядка 65 Мб) : авторname date phone email cost Имя1 16.04.2014 07:16:15 79294595328 vrghjm0@gmail.com 110 Имя2 19.05.2014 06:48:26 79933782391 p25ghjgt1@ya.ru 23 имя2 08.06.2014 05:40:37 79812440379 h7ghgfh48@list.ru 15 JAVA лучшее время read file 899 ms Код: java 1. 2. 3. 4. 5. 6. 7. total heap usage:1,000,023 allocs, 1,000,023 frees, 86,061,056 bytes allocated Код: plaintext 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. (Тут есть один нюанс - если читать в с++ файл построчно - не в массив ,то время будет в два раза лучше , чуть больше 65 ms) Хм.. У меня не такой большой отрыв. Java GCC 4.6.2 MS VS 2010 (дабл кликом по exe'шнику) Из-под визуал студии (не дебаг)220Mb (Cp1251; 1 000 000 строк) 2758.562927 ms 2312 ms 2500 ms 3187 ms На твоих данных тоже отрыв меньше. Java GCC 4.6.2 MS VS 2010 (дабл кликом по exe'шнику) Из-под визуал студии (не дебаг)57Mb (UTF-8; 1 000 000 строк) 1134.198872 ms 765 ms 796 ms 1375 ms54Mb (Cp1251; 1 000 000 строк) 1112.455888 ms 734 ms 796 ms 1344 ms "Твои данные" получил так: TextGen.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. Сравнение не совсем чесное. Если в java длина строки будет больше буффера - буффер увеличится (создастся новый массив, а значения из старого будут скопированны в новый). В С++ программе строка длинее буфера будет просто обрезана. (с utf-8 кодировкой эта C++ программа тоже работать не умеет.. просто байты) Всякие настройки C++ компилятора не крутил ибо не умею. Твой код маленько отрефакторил 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. ReadFile.cpp Код: plaintext 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. До того как порефакторил было также. Правда найти под виндой правильный аналог sys/time.h ума не хватило. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 10:24 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
avp.mk, у вас - смешанный бенчмарк. Он меряет и IO и аллокацию списков. Это создаёт некоторую путаницу. Мы не в состоянии делать выводы. У вас - однопоточное приложение поэтому вы можете детектировать раздельное время на эти две операции. Шаблон Files.readAllLines доступен в исходниках поэтому его тоже можно развалить на атомы и сделать отдельные счётчики по диску и работе со строками и списками. Если ваш код работает слишком быстро - то вы его запускаете многократно и меряете average. Если у вас два теста то вы запускаете их поочерёдно Test1, Test2, Test1, Test2 и тоже усредняете результаты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 12:20 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
maytonПостановка немного абсурдна. Если вам "прилетел" файл - то пускай улетает обратно. В продуктиве нет таких постановок. +! аффтару в конторе заняться нечем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 12:57 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
maytonavp.mk, у вас - смешанный бенчмарк. Он меряет и IO и аллокацию списков. Это создаёт некоторую путаницу. Мы не в состоянии делать выводы. Бенч как раз хороший, ровно то, что просил _автор_ топика. У меня такой же результат "Java vs C-код - ничья", при этом C код в режиме debug /без оптимизации/ значительно проигрывает Java. А вообще Assembler всех забивает с огромным отрывом ))). А мерить и нечего: IO - что C, что Java даст одинаковую скорость. Это целиком зависит от дисков и ОС. Последующая обработка - разделение на строки (по символу '\n') и парсинг ('\t'). Код на C _всегда_ будет в выигрыше, но скорее всего менее универсален/функционален. Выделение памяти - Java значительно быстрее (мерил лет 10 назад), но проблемы с GC. Если GC не работает (заранее правильное выделение памяти), то Java и C# уделывают C. Компактность хранения данных в памяти - C/C++ выигрывает с отрывом. На C/C++ можно хранить значительно компактнее, на Java классы более универсальны и нет возможности адресной арифметики (указателей) C. etc... Данные вещи вроде как очевидны исходя из архитектуры. Мерить смысла нет. Кому нечем заняться, могут пытаться написать корректный ))) бенчмарк и заняться холеваром. schwaСравнение i/o на java и на c/c++ в основном это замеры оверхеда от выделения памяти виртуальной машиной т.к. все массивы байт скопируются по N-раз пока дойдут до места, где java-разработчик может ими начать оперировать. IMHO Оверхид достаточно маленький. AFAIK: 1) На Java выделение памяти практически "бесплатно" с точки зрения CPU. Все проблемы с аллокацией проявятся только на стадии GC. Особенно в нормально нагруженном продакшене. Когда пара десятков юзеров будет разом eden область в куче засирать. 2) Тупое копирование строки операция крайне быстрая. Т.к. оптимизирована под CPU. Тут больше имеет проблема промахи предсказателя переходов и кеша. Без промахов, скопировать пару десятков байт дешевле, что с промахами проверить один символ на равенство \n' ))). Но это очень сильно тюнеть программу нужну. И ставить Intel VTune, что бы смотреть, какие конвейеры в процессоре затыкается. В данном случае, все исключительно зависит от качества JIT-компилятора. При ООП программирование и одинаковых классах, JAVA, скорее всего, даст более высокую скорость, чем C++. Вызов виртуального метода JIT-компилятор заинлайнить может, а C++ компилятор нет. Сравнивать C-код и Java-код очень сложно. Больно все разное. С-код без ООП скорее всего будет на порядки быстрее любого ООП-шного. Но и, скорее всего, менее функционален. Т.к. никто в здравом уме, не будет самопальную поддержку 100500 кодовых страниц реализовывать. Тут выбор: или скорость или универсальность. Ну и нормальный C-программисту и в голову не придет, для задачи "...просят вас что то посчитать в этом файле - что то найти..." 15579898 городить списки и затаскивать миллионно-строчный файл в память. Все "посчитают и найдут" просто проходом по байтовому массиву. ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 14:05 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Потому что код плюсов и код жабы не идентичен. String в жаве - более высокоуровневая сущность, чем char* Само io знамает одинаковое время: Код: 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. Результат: Read file 108 ms. Parse file: 1415ms Lins count= 1000000 На стандартных настройках gc. Тут надо сказать почему вышло такое время парсинга. В жабе в хотспоте размер класса,c учетом всех выравниваний, кратен 64байтам. На многопоточных программах это дает мегпреимущества. Это значит, что когда делается new String, то создается несколько обьктов суммарным обьемом кратным 64. Попытаемся прикинуть сколько обьектов создается и сколько они займут Естественно, приблизительно: Сами обьекты String - 1000000, внутри каждого String есть char[] -- тоже 1000000 инстансов. каждый стринг - считаем 64байта, каждый char - два байта, строка около 60символов, это 120 байт, плюс заголовок у каждого обьекта где-то 12 байт. Т.е., ближайшее большее кратное длине кешлайна -- 192байта. Таким образом, на каждый стринг на все его инстансы надо 256байт минимум. И если у нас EDEN меньше суммарного обьема всех этих данных, то очевидно, что копирования не избежать. Хотим быстро отпарсить 1М таких строк - выделите не менее 256мб EDEN. И это оценка снизу, т.е. на практике нужно больше. Проверим это. Запустим парсинг с параметрами -Xms3584m -Xmx3584m , получаем 759мс, против 1533мс. Уже лучше. Это раз. Два, как сказано выше, char* в сях и String не развнозначные классы. Чтобы сказать сколько символов в char*, надо затратить некоторое время, чтобы их подсчитать (и с учетом кодировки, побайтовая длина не подходит), а String тратит это время на этапе создания. Плюсы вообще, насколько знаю, не умеют работать с utf-8, в них есть wstring в которых 1 символ - 4 байта. C++11 вводит u16string, но на сегодня gcc который это может отктпилить, в стандартных репозиториях нет. Вообще же, в седьмой жаве убрали "некопируемость" данных из строк для того чтоб работал escape-анализ. Для быстрой работы с большми строками рекомендуют direct ByteBuffer и CharSequence. Если мы хотим аналогии с плюсами, действовать надо так -- сначала читаем все в ByteBuffer, после чего находим индексы всех \n и прибавляем к ним 1 - это будут указатели, аналог char*. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 16:11 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
ivanra1000000 строк - 1000000 раз будет создаваться и компилироваться Pattern, скорее всего, можно ускорить разбор, заготовив Pattern заранее.... не подтвержденные сведения, но похоже на правду: автор... В Java 7 разбиение на подстроки, в случае если шаблон состоит из одного символа, было оптимизировано в методе String.split. Всегда используйте этот метод для разбиения на подстроки в Java 7... (C) http://java-performance.com/ru/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2014, 19:46 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
UP вот нашел задачу , которая не проходит на 11 тесте по времени ...его просто не хватает ... какие могут быть решения? https://acmp.ru/index.asp?main=task&id_task=41 На планете «Аурон» атмосфера практически отсутствует, поэтому она известна своими перепадами температур в различных точках. Известно, что эти перепады колеблются от -100 до 100 градусов. Нашим специалистам удалось выяснить значения температур в N точках этой планеты. К сожалению, эти значения вычислены с большими погрешностями, поэтому их решили округлить до целых чисел. Хотелось бы наглядно видеть участки с повышенной и пониженной температурой. Вам требуется помочь. Вы должны упорядочить температуры участков по неубыванию. Входные данные В первой строке входного файла INPUT.TXT задано натуральное число N - количество участков (N <= 10^6). Во второй строке через пробел записаны целые значения температур этих участков, не превосходящие 100 по абсолютной величине. Выходные данные В единственную строку выходного файла OUTPUT.TXT нужно вывести разделенные пробелом значения температур всех известных участков, которые должны следовать друг за другом в порядке неубывания. мое решение : Код: 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. падает на 11 Time limit exceeded 2,145 7,9 Мб Менял на Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. падает на тесте 9 Memory limit exceeded 0,522 26 Мб Нужно найти быстрое чтение , запись в файл + быстрый разбор строки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 10:30 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1, авторВ качестве критерия ранжирования лучших попыток служит размер кода закачиваемой программы. OMFG... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 10:45 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1, Убери конкатенацию строк. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 10:54 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczAtum1, авторВ качестве критерия ранжирования лучших попыток служит размер кода закачиваемой программы. OMFG... да, все честно ) самые быстры и короткие Это https://acmp.ru/index.asp?main=bstatus&id_t=41 Python и С++ как правило ... по всем задачам .. что говорит о выразительности языка ... его скорости итд ... для олимпиад самое то ... Правда меня иногда ставит в замешательство когда находятся люди предложившие решение на java в 135 строк - вопрос только один как ? как они такое смогли сжать код ???? по некоторым задачам . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 10:55 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1, flush() не нужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 10:56 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1что говорит о выразительности языка ... Питон он вообще заточен под подобные задачи. С плюсами просто всё понятно. А в Java у нас ООП. Только объекты и методы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 11:00 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczAtum1, Убери конкатенацию строк. 201 значение это долго? в каком месте ? я уже и строку пытался читать посимвольно(нахожу число - добавляю в массив ) все равно медленно . :( ps офф https://acmp.ru/index.asp?main=task&id_task=1 вопрос как : получить 135 ? ЗАДАЧА №1 A+B (Время: 1 сек. Память: 16 Мб Сложность: 2%) Требуется сложить два целых числа А и В. Входные данные В единственной строке входного файла INPUT.TXT записано два натуральных числа через пробел, не превышающих 109. Выходные данные В единственную строку выходного файла OUTPUT.TXT нужно вывести одно целое число — сумму чисел А и В. размер 300 Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 11:00 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczAtum1что говорит о выразительности языка ... Питон он вообще заточен под подобные задачи. С плюсами просто всё понятно. А в Java у нас ООП. Только объекты и методы. Была идея прорешать все задачи на java чисто в функциональном стиле ... но очень многие решения не проходят в таком стиле по памяти и времени :( Это печалит ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 11:03 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Размер кода: 199 ! максимум. https://acmp.ru/index.asp?main=task&id_task=1 Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 11:14 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
chabapok Два, как сказано выше, char* в сях и String не развнозначные классы. Чтобы сказать сколько символов в char*, надо затратить некоторое время, чтобы их подсчитать (и с учетом кодировки, побайтовая длина не подходит), а String тратит это время на этапе создания. Вы путаете реализацию языка и библиотеки! Начнем с того, что char* это ни разу не класс, а указатель! Для примера вопрос - на какой тип указывает указатель void*? chabapok Плюсы вообще, насколько знаю, не умеют работать с utf-8 Это равносильно заявлению, что ключем 10х12 нельзя ремонтировать автомобили Хонда. Плюсам глубоко фиолетово на кодировку, они работают с байтами, словами и другими типами. Работа с кодировками это прерогатива программиста. Что накодит, то и получит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 11:16 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Код: java 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 11:22 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowicz Код: java 1. 2. 3. 4. 5. 6. 7. 8. 144 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 12:53 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1, Код: java 1. 2. 3. 4. 5. 6. 7. 8. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 13:06 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1 размер 300 Слишком много букафф пишешь. :) D 300 включая пробелы влезяет и посложнее задача Код: java 1. И то можно лишние проверки убрать :) Можно и конкатенакцию вернуть. Пускается и с -Xmx1m -XX:MaxMetaspaceSize=2368K на 32-хбитной 8-ке ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 13:07 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1 144 public у класса не нужен, так как мы в рутовом пакете - это -6 args заменить на одну букву - 3 итого - 135 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 13:16 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowiczpublic у класса не нужен, так как мы в рутовом пакете - это -6 args заменить на одну букву - 3 итого - 135 А еще имя класса уменьшить - вообще рекордсменом станет. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 13:28 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевА еще имя класса уменьшить - вообще рекордсменом станет. :) Ты условия, по ходу, не читал. Имя класса - Main. Пробелы, табы и переносы строк при подсчете не участвуют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 13:30 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевAtum1 размер 300 Слишком много букафф пишешь. :) D 300 включая пробелы влезяет и посложнее задача Код: java 1. И то можно лишние проверки убрать :) Можно и конкатенакцию вернуть. Пускается и с -Xmx1m -XX:MaxMetaspaceSize=2368K на 32-хбитной 8-ке не проходит... видимо Scanner очень медленная хрень . 11 Time limit exceeded 2,177 6,9 Мб Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 13:39 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczТы условия, по ходу, не читал. Имя класса - Main. Это я не прочел - оно ж в решении всплыло и именно для java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 13:39 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев (Время: 2 сек. Память: 16 Мб Сложность: 29%) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 13:42 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1не проходит... видимо Scanner очень медленная хрень . Попробуй в буфер завернуть in и out. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 13:45 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczСергей АрсеньевА еще имя класса уменьшить - вообще рекордсменом станет. :) Ты условия, по ходу, не читал. Имя класса - Main. Пробелы, табы и переносы строк при подсчете не участвуют. Бинго :) Код: java 1. 2. 3. 4. 5. 6. 7. 135 pascal 33 python 34 135:33 = 4 ! к вопросу о языках https://habrahabr.ru/company/alconost/blog/197146/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 13:49 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1[11 Time limit exceeded 2,177 6,9 Мб Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. видимо есть какой-то вырожденный случай : 1)где долго работает Scanner 2)сложность O(n^2) в цикле где 2 фора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 13:56 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1видимо есть какой-то вырожденный случай : Сканер на миллионе чисел сработает долго и у меня (регэксп внутри). Но дольше System.out. Если сделать через StringBuilder то букв больше Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 15:29 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
хотя без catch оно даже меньше Код: java 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 15:35 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1видимо есть какой-то вырожденный случай : 1)где долго работает Scanner 2)сложность O(n^2) в цикле где 2 фора. Буферизацию может таки добавим? Худший случай это максимум значений "-100". Этот случай даёт самые длинные входные и выходные файлы. Плюс максимальное количество циклов вывода = (n * 2) - 1. Как там нарисовать O(n^2) - мне не понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 15:37 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев, В StringBuilder стоит capacity добавить. ХЗ как они там память считают. Но строка в 5млн символов это уже 10Мб при потолке в 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 15:42 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczAtum1видимо есть какой-то вырожденный случай : 1)где долго работает Scanner 2)сложность O(n^2) в цикле где 2 фора. Буферизацию может таки добавим? Худший случай это максимум значений "-100". Этот случай даёт самые длинные входные и выходные файлы. Плюс максимальное количество циклов вывода = (n * 2) - 1. Как там нарисовать O(n^2) - мне не понятно. пробовал - вылетает по памяти на 9 тесте . Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. по времени 11 Time limit exceeded 2,147 39 Мб ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 16:15 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1, Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 16:33 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczAtum1, Код: 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. Тест Результат Время Память 1 Wrong answer 0,191 725 Кб ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 16:38 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, Если по скорости пролезет - синтаксис можно немного ужать чтобы в топ выйти. В if/else стоит числа проверять до знака, так как они по статистике должны быть чаще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 16:43 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Пережал до 320. Над циклом вывода сильно не думал. Может там ещё что-то можно почикать... Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 16:47 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczПережал до 320. Над циклом вывода сильно не думал. Может там ещё что-то можно почикать... Код: 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. 1 Wrong answer 0,215 157 Кб где то ошибка в алгоритме . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 17:18 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowicz Код: java 1. Косячок-с. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 17:19 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1где то ошибка в алгоритме . При компрессии налажал с чаром. Но что в первом варианте не так было не врублюсь. Мои тесты нормально сортирует :(. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 17:25 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczПри компрессии налажал с чаром. Но что в первом варианте не так было не врублюсь. Мои тесты нормально сортирует :(. Кажется дошло. Просто я тупой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 17:30 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Код: 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. Можно попробовать ещё знак n упаковать в значение v. Но вряд ли получится меньше кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 18:07 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
313! А память там реально от балды считается. Прыгает от 7,5 до 9,5 на идентичном коде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 18:28 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
307 и я уже заколебался. Код: 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. Если у кого есть идеи куда дальше ужимать - с радостью выслушаю. Второй цикл можно через while написать, длинна выходит точно такая же. От третьего условия избавится не получилось, хотя есть чувство, что можно. Не выяснил ещё есть ли в тестах хвостовой пробел. Возможно с этим знанием можно как-то условия сократить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 19:15 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczЕсли у кого есть идеи куда дальше ужимать - с радостью выслушаю. Проблема блин в System.out - у меня медленный. (Чисто печать - разбор и на стримсах копейки по времени). Из-за двухбайтовой кодировки - одного SB + оно же напечатать - много. P.S. Код: java 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 20:12 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев Код: java 1. 2. Вот спасибо! Этот инлайн я провтыкал. У меня ещё на счёт вывода есть идеи, но с наскока не получилось сократить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 20:40 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, да тут ещё выкидывать и выкидывать. Оба умножения я провтыкал. В выводе можно одну переменную вообще выкинуть. Попробую завтра до 300 добить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 22:34 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczУ меня ещё на счёт вывода есть идеи, но с наскока не получилось сократить. Еще символ хотел выкинуть? Код: java 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 22:38 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
но это чертовски медленно, а ускорение, по типу Код: java 1. 2. 3. требует много символов :( Есть вариант String не объявлять, но требует хотя бы одного параметра при вызове. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 23:45 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев, Да, так и сделал. Хочу ещё первый цикл выкинуть, так как он длинный. Но слишком много новых условий выходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 23:50 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
298! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.02.2017, 23:54 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1 Код: java 1. Не позорься. Когда ты писал хакатоны со Streams - то это было респектабельно и красиво. И я тебя уважал. Но перфрманс - это явно не твоё. split никогда не работал эффективно. Если ты хочешь производительность - то никаких аллокаций и сплитов. Пили свой FSM и парсер текстового стрима. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 00:05 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
287 после слияния циклов чтения. Код: 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. И никакой обфускатор не нужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 00:18 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
285... единственное жирное место это отдельная переменная под знак. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 00:44 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowicz Код: java 1. Код: java 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 06:38 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Usman, Я в курсе. Но в этом дурацком конкурсе борьба за код, а не за производительность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 06:50 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, ок. тогда все for'ы заменить на while ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 06:53 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Usmanтогда все for'ы заменить на whileи вроде бы все ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 06:57 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Usmanтогда все for'ы заменить на while Вот что значит свежим взглядом! Я уже и не заметил. Вот только проблема в том что while и for;; - оба пять символов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 08:27 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Usmanи вроде бы все Ну, у меня есть несклько идей. Например, как бы последнее условие выкинуть. Тогда n может быть 1 или -1, без 0. Но тогда выходит ложный инкремент для значения 0. То ли пробел у них в конце тестовых файлов, то ли перенос строки. И ещё вместро тренарного оператора что-то покороче хочется. Ведь в обоих использованиях по условию нужно поменять значение или оставить прежнее. Вот это "оставить прежнее" это излишняя информация в коде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 08:38 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Второй тренарный заборол. 280. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 08:53 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczНо в этом дурацком конкурсе борьба за код, а не за производительность. Однако ж, когда я пускаю у себя миллион out.print() - я не укладываюсь в 2 сек (с перенаправлением выхлопа в файл). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 09:18 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Можно и первый тренарый забороть. Но выходит 281 :( Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 09:37 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевОднако ж, когда я пускаю у себя миллион out.print() - я не укладываюсь в 2 сек (с перенаправлением выхлопа в файл). Локально тестируешь? Напиши Java обертку для запуска. Похоже у них там System.in и System.out быстрый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 09:39 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
278 и ну его нафиг... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 09:50 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, внесу свои 5 копеек. А вот так можно заменить в Java? было Код: java 1. стало Код: java 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 09:58 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
SQL2008, Нельзя. Это же не JavaScript. Строгая типизация и всё такое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 10:03 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, там еще и Код: java 1. 2. 3. Но это наверное, ты и сам заметил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 10:03 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, жаль. Я думал как в С++, допустима простая проверка на 0. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 10:04 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
maytonAtum1 Код: java 1. Не позорься. Когда ты писал хакатоны со Streams - то это было респектабельно и красиво. И я тебя уважал. Но перфрманс - это явно не твоё. split никогда не работал эффективно. Если ты хочешь производительность - то никаких аллокаций и сплитов. Пили свой FSM и парсер текстового стрима. Да дело не в перфомансе :) Я еще раз повторюсь - идея была - решать все в функциональном стиле одной строкой . и данное решение как раз их таких . проблема возникает в ограничениях - и нужно искать компромисс - ужимать код , писать свои реализации итд ... да, split - не быстр , хотя и обещали его ускорить ... да можно написать свой парсер , и так и нужно делать . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 10:10 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
277. Когда же меня наконец отпустит. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 10:11 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczМожно и первый тренарый забороть. Но выходит 281 :( Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Спасибо ! Вы сделали мой день ! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 10:17 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
277 Это очень круто ... по времени - и памяти - там у них виртуалка и часто в обсуждениях пишут такое - попробуйте запустить код в другое время ... бывает что не хватает каких то сотых секунд . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 10:20 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1Я еще раз повторюсь - идея была - решать все в функциональном стиле одной строкой . Решение было в количестве символов. Но укладываясь в память. Из-за двухбайтовой кодировки входной поток из 5 000 004 символов легко занимает 10 миллионов байт. Плюс сплиты и сортировка и jvm съела больше 16 Mb Причем при этом Hotspot вылезает за установленные лимиты параметры-Xmx12412K -Xss24K -XX:MaxMetaspaceSize=2648K Main <input2.txt >out.txt а java.exe взяла 20M (Без стримов остается внутри них). Плюс куча импортов, да и превлатить исходный поток в поток (простим авторам их стеб) А так да - решение получилось небольшое. Код: java 1. 2. 3. 4. 5. 6. 7. Правда должен же быть способ потратить меньше букв на превращение в поток. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 10:57 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Exception лишний ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 11:00 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев261 Да. Все верно . Спасибо. Все это началось когда я посмотрел пару видео где. Декларировались следующее : Век медленных компьютеров прошёл! Мы будем писать код быстро и машины будут Египте же быстро исполнять! А там где будут медленные места мы будем думать как их оптимизировать. В этом подходе есть и минусы и плюсы: Минусы в том что алгоритмы не оптимальные и на данном примере. Виден весь оверхед сплиты сортировка обычная не методом расчёта И так далее Свомьрите сами написать алгоритм в олн строку занимает минуту . Написать эффективный Алгоритм без ошибок куда дольше. И вот нужно найти компромис . Между эффективностью и скоростью разработки . К тому же эффективный алгоритм сложен для понимания , через какое то время будет не легко понять что в нем происходит на уровне байт И так далее Но именно это и есть программирование. И написанные алгоритмов . Функциаональный стиль дал возможность легко понять что делает этот код он локаричен и краток но н эффективен. В производстве . Вопрос философский где золотая середина ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 11:25 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Но на сколь-ко-нибудь несортированных данных вылетает по времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 11:29 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сергей Арсеньев261. Превратить через Files read all lines и path вроде как можно, в этой тебе как раз это выше в начале и обсуждалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 11:29 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Про время был не прав - сам паузу влепил ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 11:38 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1, Но это тоже букавки и в т.ч. в импорте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 11:40 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Но в любом случае, если файл одна строка (две - первую пропускаем), split не укладывается в память ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 11:47 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
можно создать свой поток, но это опять много букв Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 13:56 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1Век медленных компьютеров прошёл! С одной стороны оно так. Миллион чисел сортируются за 16 ms. А с другой И этот же миллион чисел печатается за 4 699 ms. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 14:38 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевИ этот же миллион чисел печатается за 4 699 ms.+1, проблему можно решить перенаправлением потока в файл ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 14:43 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Usman+1, проблему можно решить перенаправлением потока в файл По-моему это и есть "файл". На консоль на много дольше будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 14:49 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczUsman+1, проблему можно решить перенаправлением потока в файл По-моему это и есть "файл". На консоль на много дольше будет.Если быть точнее, то так и есть. Проблема с отрисовкой символов в окне, скролл, буферизация окна и пр. тормоза ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 14:52 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczUsman+1, проблему можно решить перенаправлением потока в файл По-моему это и есть "файл". На консоль на много дольше будет. у них по умолчанию чтение данных берется из файла input.txt запись идет в output.txt так что можно попробовать . Это отличное решение ! можно так же указать размер - для параллельного сплитератора - ибо мы знаем сколько будет чисел. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 14:57 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Atum1у них по умолчанию чтение данных берется из файла input.txt запись идет в output.txt Это всего лишь имена :D. Они не дают никакого представления о том что происходит на физическом уровне. Факт в том что работа с System.in/System.out у них происходит быстрее чем банальный java Main < input.txt > output.txt на HDD, который без буфера в 2 секунды никак не укладывается. Скорее всего файлы лежат в памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 15:02 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowicz Скорее всего файлы лежат в памяти. А нафиг им творчество - логично что файлы создаются на рамдиске. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 15:52 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Сергей АрсеньевА нафиг им творчество - логично что файлы создаются на рамдиске. Выходит что буферизация в этих задачах не нужна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 15:54 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, Им - нет. Наверное. Ибо если ФС не игнорирует flush, то миллион out.print за 2 секунды, это 500K IOPS; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 16:01 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Пятница. 275. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2017, 17:40 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
Я тут сумму двух чисел настрочил. Но, к сожалению, 151 выходит. Слишком много на фоне 135 со сканером. Код: java 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2017, 17:47 |
|
||
|
Быстрое чтение и разбор файла
|
|||
|---|---|---|---|
|
#18+
BlazkowiczЯ тут сумму двух чисел настрочил. Но, к сожалению, 151 выходит. Слишком много на фоне 135 со сканером. Код: java 1. 2. 3. 4. 5. 6. 7. ААА !!! Это топ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2017, 16:36 |
|
||
|
|

start [/forum/topic.php?all=1&fid=59&tid=2123129]: |
0ms |
get settings: |
11ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
88ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
175ms |
get tp. blocked users: |
2ms |
| others: | 235ms |
| total: | 553ms |

| 0 / 0 |
