Java big file read

думаю, что NIO тут никак особенно не поможет, поэтому просто вот так:

try(BufferedReader br = new BufferedReader(new FileReader(file))) {
    for(String line; (line = br.readLine()) != null; ) {
        //обработка строчки
    }
}

+1

И это все, что ЛОР может сказать о яве и производительности?

Даже ничего не скажешь о том, что строить каждый раз объект String дорого и лучше заюзать char[]?

mmap() и шаришься спокойно себе по замапленному в память файлу

шо, жаба так не умеет? :)

зачем ты так с ними... у них сегодня праздник

Files.lines()

Можно, но не понятно зачем.

Даже ничего не скажешь о том, что строить каждый раз объект String дорого и лучше заюзать char[]?

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

Не скажу, по сравнению с IO - не дорого

Files.lines(..)
@since 1.8

Умеет, но последовательное чтение файла быстрее чем mmap

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

умеет. через jni

А что, все сишники для последовательного чтения «шарятся по файлу»? То-то у меня линукс тормозит.

Суть в том, чем быстрее и оптимальнее всего читать большие файлы построчно в яве?

Гораздо интереснее как и куда складывать прочитанное, потому чо джава - такая джава:

SimpleMapStorage consumes 706 Mb to store 1M records. The actual data size is about 82 Mb, which means that this simple implementation wastes about 85% of consumed memory. Yes, straightforward solutions for big data storage do not work well in Java…

М, интересно. Казалось бы, стандартные библиотеки должны быть на столько вылизаны, что вопросов об их эффективности оставаться бы не должно (привет С++).

А какая разница, 5 мегабайт или 50 гигабайт? Даже если сейчас 5 мегабайт, через неделю будут гигабайты, если не террабайты. Эффективные программы надо писать сразу, а не только когда смартфон не справляется.

Правда? Мне кажется, ты и сам не знаешь, что там у тебя будет: если на самом деле терабайты, то все ясно и без вопросов, а если нет, то тебе вообще пофиг.

Большой - это насколько большой?

Какова нынешняя реализация? Если пока никакой реализации нет, то откуда вообще возник вопрос об оптимизации?

нынешняя реализация юзает BufferedReader, вопрос возник из того, что я не настолько хорошо знаю все эти загоны и 100500 способов чтения файлов в java

Ну и пусть остаётся нынешняя. А вопросы о способах чтения можно и по руководствам выяснить.

Было бы интересно, если бы рядом было сравнение с каким-нибудь c++ и хранением данных в stl map и String, а так естественно, что выбрав неэффективное хранилище память будет использоваться неэффективно.

только wstring, а не string.

для чистоты эксперимента конечно лучше wstring, но и обычного string хватит, чтобы понять, что это не в джаве проблемы.

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

какое эффективное хранилище можете предложить для пар ключ-значение, желательно с возможностью сортинга по значению

какое эффективное хранилище можете предложить для пар ключ-значение

В том-то и дело, что в том примере не нужно использовать хранилище ключ-значение, что и было сделано в первой же оптимизации.

желательно с возможностью сортинга по значению

какое из использовавшихся в том примере хранилищ позволяло это?

на пример не смотрим, смотрим на мой вопрос :)

java и без jni умеет.

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

тоесть, в строке 3 значения, разделенные точкой с запятой. Второе значение может повторяться неограниченное кол-во раз, третье надо суммировать для каждого повторяющегося второго.

что непонятно диванным бехевиористам?

тоесть, в строке 3 значения, разделенные точкой с запятой. Второе значение может повторяться неограниченное кол-во раз, третье надо суммировать для каждого повторяющегося второго.

что непонятно диванным бехевиористам?

непонятно то, что ты с одного вопроса на другой перескакиваешь, я смотрел на вот этот:

какое эффективное хранилище можете предложить для пар ключ-значение, желательно с возможностью сортинга по значению

а в начальном было вообще про то как эффективно прочитать файл.

также непонятно с чего ты вообще решил что тебе нужно какое-то хранилище, да ещё и с сортировкой по значению.

Даже ничего не скажешь о том, что строить каждый раз объект String дорого и лучше заюзать char[]?

В примере выше и так используется char[] - открой реализацию readLine. readLine вернёт char[] от BufferdReader с нужными start & end индексами в виде String. Копирование будет, только если в BufferdReader не хватит размера буфера.

Создаешь хешик и читаешь файлик построчно, проблема то где? что оптимизировать?

Эффективные программы надо писать сразу, а не только когда смартфон не справляется.

Диагноз: преждевременная оптимизация, оптимизация без профилирования и оптимизация нужность которой совершенно сомнительна.

Закончи лучше остальную часть системы, чтобы работала с файликом 5 мегабайт, а потом будешь оптимизировать имея реальные данные и замеры. Или не будешь, потому что окажется что проект никому не нужен даже с оптимизациями.

Да, и напоследок подумай про степень важности свойств софта (по psychology of computer programming):

1. Корректность
2. Планируемость, сроки
3. Поддерживаемость
4. Скорость

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

Смотри, допустим ты провел 4 часа выясняя все 100500 тонкостей чтения файла и спрашивания на лоре и еще где-нибудь. В результате ты получишь более быструю версию, но не оправдывающую себя в данный момент, т.к. файл маленький.

Но пока у тебя файл, например неделю, еще не будет больше 10 метров, ты мог написать свою функцию за 30 минут с чтением файла полностью в память и оставшиеся 3.5 часов потратить на что-то более полезное прямо сейчас. Простой расчет полезности твоего труда.

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

а тебе только прочитать надо? обрабатывать не требуется?

средствами String нет