Быстрое чтение и разбор файла / Java

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Java [игнор отключен] [закрыт для гостей] / Быстрое чтение и разбор файла

25 сообщений из 158, страница 2 из 7

все

Быстрое чтение и разбор файла

#38563721

Atum1

Участник

Откуда: СПБ

Сообщения: 1 847

Рейтинг: 0 / 0

Leonid Kudryavtsev,
К тому же, совершенно не понятно. ЗАЧЕМ это нужно. Один раз считать файл при загрузки приложение, что 0.5 сек, что 5 сек - роли большой иметь не должно. Нужна сверх скорость (близкая к ассемблеру) - перерабатывать постановку, делать нормальные форматы хранения данных и на диске и в памяти. Загонять миллионы объектов в LinkedList лично мне Java'у было бы жалко ))) Но я программировать учился на 286 с 1 Mb ОП и там ГИС писал (ГеоИнформационная система), т.ч. уже при словах LinkedList, миллион объектов мне компьютер и процессор жалко становится. Жалостливый я очень ))).

Скажем так - всегда считал что это быстро , когда писал такой код - и не задумывался о том 0.5 или 5 сек.

но когда решил проверить как такое же будет проходить в С++ или через простой awk - понял насколько медленно это делает JAVA

...

Рейтинг:

0 / 0

17.02.2014, 22:40

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38563722

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Исходные данные: лям строк, 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 компилятор делает крайне странно.

...

Рейтинг:

0 / 0

17.02.2014, 22:42

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38563724

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Насколько я помню по C++: все listы - бяки, деревья - еще большие бяки. Array'и намного лучше. Компактнее лежат в памяти, при больших объемах значительный выигрыш по памяти и соответственно по производительности.

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

IMHO (на истину не претендую): Если eden достаточный, то лишние объекты и копирование туда-сюда сильно больших проблем создавать не должно. А вот old-gen heap работает значительно медленнее.

Для системы, если действительно нужно держать миллионы строк в памяти - я бы пытался хранить наиболее компактно. Java для этого, к сожалению, не самый лучший инструмент. ООП однако.

Ну и задача мне СОВЕРШЕННО НЕ ПОНЯТНА? Почему, если обработка данных настолько критична, ТЕКСТОВЫЙ файл?

...

Рейтинг:

0 / 0

17.02.2014, 22:50

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38563731

DEVcoach

Гость

Leonid KudryavtsevНу и задача мне СОВЕРШЕННО НЕ ПОНЯТНА? Почему, если обработка данных настолько критична, ТЕКСТОВЫЙ файл?Да всякое бывает. Почитайте, например, чем занимается компания Splunk. У них как раз джавовский продукт, который должен максимально быстро перелопачивать именно текстовые данные. Ничего в этом странного нет.

...

Рейтинг:

0 / 0

17.02.2014, 23:03

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38563733

Atum1

Участник

Откуда: СПБ

Сообщения: 1 847

Рейтинг: 0 / 0

Leonid Kudryavtsev
Ну и задача мне СОВЕРШЕННО НЕ ПОНЯТНА? Почему, если обработка данных настолько критична, ТЕКСТОВЫЙ файл?

Прилетел вам от клиента файл такого формата , строки с какой-то инфой разделенные табами...

Ну удобно им в файл писать - в виде имя \t номер телефона \t дата \t почта \t адрес итд...

и просят вас что то посчитать в этом файле - что то найти ...

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

и действительно проверил : оставил только счетчик

Код: java

1.
2.
3.
4.
5.
6.

BufferedReader in = new BufferedReader(new InputStreamReader(NewClass.class.getResourceAsStream("in.txt")));
        String str = null;
        int c=0;
        while ((str = in.readLine()) != null) {
        c++;
        }

и аналогичный код на с++ через fopen и увидел что это в разы быстрее ... вот и задумался ...
(Хотя к слову сказать - в C++ можно получить результаты отличающиеся в 2 раза - только используя более свежую версию компилятора, но в любом случае на порядок быстрее чем в java)

чудеса.

поэтому и решил спросить - так ли это ? может кто знает почему так медленно ? где тут потери? в чем ?
на будущее чтобы знать ?

и чтобы лучше понимать этот волшебный мир java ! :)

...

Рейтинг:

0 / 0

17.02.2014, 23:09

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38563744

Atum1

Участник

Откуда: СПБ

Сообщения: 1 847

Рейтинг: 0 / 0

Всем спасибо!

ответы тут :

http://nadeausoftware.com/articles/2008/02/java_tip_how_read_files_quickly

...

Рейтинг:

0 / 0

17.02.2014, 23:29

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38563857

avp.mk

Гость

Atum1но когда решил проверить как такое же будет проходить в С++ или через простой awk - понял насколько медленно это делает JAVAAtum1и аналогичный код на с++ через fopen и увидел что это в разы быстрее ...
Показывай полный код на java и полный аналогичный код на c++.

P.S. Arrays.asList и так возвращает (фактически) ArrayList незачем здесь создавать ещё один ArrayList (и копировать в него все элементы..), readLine, split и LinkedList тоже плохие слова.

...

Рейтинг:

0 / 0

18.02.2014, 07:56

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564017

Garrick

Участник

Откуда: Москва

Сообщения: 2 870

Рейтинг: 0 / 0

BlazkowiczПопробуй размер буфера побольше указать. Для больших файлов может помочь.
В данном случае, для правильной оптимизации, ещё необходимо подобрать размер буфера кратный размеру строки в файле. При "неправильном" размере буфера эффект может оказаться отрицательным.

...

Рейтинг:

0 / 0

18.02.2014, 10:30

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564056

Atum1

Участник

Откуда: СПБ

Сообщения: 1 847

Рейтинг: 0 / 0

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.

public static void main(String[] args) throws IOException, Exception {
     long time = System.currentTimeMillis();
        List<String> lines = Files.readAllLines(Paths.get("stat.txt"), Charset.forName("UTF-8"));
        System.out.println(lines.size());
     long t1 = System.currentTimeMillis() - time;
     System.out.println(" read file " + (t1) + " ms");
  }

С++ 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.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unordered_map>
#include <string>
#include <stdint.h>
#include <vector>
#include <sys/time.h>
#include <list>


#define BUF_LINE_SIZE	2048

int main( int argc, char ** argv )
{
	std::vector<char *> lines_list;
	std::vector<char *>::iterator lit;
	FILE * fp;
	char line[BUF_LINE_SIZE];
	char * cptr;
	unsigned long linescount = 0;
	struct timeval t1, t2;
	uint64_t mscount;

	if ( 2 != argc )
	{
		printf( "usage: testp1 <infile>\n\n" );
		return 1;
	}

	fp = fopen( argv[1], "r" );
	if ( ! fp )
	{
		printf( "can't open file %s for read\n\n", argv[1] );
		return 2;
	}

	gettimeofday( &t1, 0 );

	for ( cptr = fgets( line, BUF_LINE_SIZE, fp ); cptr; cptr = fgets( line, BUF_LINE_SIZE, fp ) )
	{
		lines_list.push_back( strdup( cptr ) );
		++linescount;
	}
	gettimeofday( &t2, 0 );
	fclose( fp );
	mscount = (t2.tv_usec + (((uint64_t)t2.tv_sec)*1000000ULL))
		- (t1.tv_usec + (((uint64_t)t1.tv_sec)*1000000ULL));
	printf( "done, result %lu lines at %llu.%06llu seconds\n\n"
		, linescount, mscount / 1000000ULL, mscount % 1000000ULL );

	for ( lit = lines_list.begin(); lines_list.end() != lit; ++lit )
	{
		free( *lit );
	}
	return 0;
}

(Тут есть один нюанс - если читать в с++ файл построчно - не в массив ,то время будет в два раза лучше , чуть больше 65 ms)

...

Рейтинг:

0 / 0

18.02.2014, 10:49

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564140

just_vladimir

Участник

Сообщения: 864

Рейтинг: 0 / 0

Atum1 JAVA лучшее время read file 899 ms

Код: java

1.
2.
3.
4.
5.
6.
7.

public static void main(String[] args) throws IOException, Exception {
     long time = System.currentTimeMillis();
        List<String> lines = Files.readAllLines(Paths.get("stat.txt"), Charset.forName("UTF-8"));
        System.out.println(lines.size());
     long t1 = System.currentTimeMillis() - time;
     System.out.println(" read file " + (t1) + " ms");
  }

Оформите в виде jmh бенча, иначе цифры ни о чем не говорят.

...

Рейтинг:

0 / 0

18.02.2014, 11:21

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564151

Atum1

Участник

Откуда: СПБ

Сообщения: 1 847

Рейтинг: 0 / 0

just_vladimirОформите в виде jmh бенча, иначе цифры ни о чем не говорят.
тут все расписано !
http://nadeausoftware.com/articles/2008/02/java_tip_how_read_files_quickly

с 2008 года особо ничего не изменилось.

Тему можно закрыть !

Всем спасибо за помощь и участие.

...

Рейтинг:

0 / 0

18.02.2014, 11:26

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564362

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

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 миллионов объектов, что бы было - совсем не понятна. Нафига?

...

Рейтинг:

0 / 0

18.02.2014, 13:04

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564368

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Если метод подхватывается JIT-компилиром, время должно быть сравнимо. Если метод НЕ подхватывается JIT-компилиром, Java резко тормознутее. Что и понятно. Интерпретатор байт-кода.

Куча и потери на GC. При миллионах строк и миллионах объектов - отнюдь не бесплатно.

IMHO & AFAIK

...

Рейтинг:

0 / 0

18.02.2014, 13:06

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564470

mayton

Участник

Откуда: loopback

Сообщения: 53 422

Рейтинг: 2 / 0

Atum1Leonid KudryavtsevНу и задача мне СОВЕРШЕННО НЕ ПОНЯТНА? Почему, если обработка данных настолько критична, ТЕКСТОВЫЙ файл?

Прилетел вам от клиента файл такого формата , строки с какой-то инфой разделенные табами...

Ну удобно им в файл писать - в виде имя \t номер телефона \t дата \t почта \t адрес итд...

и просят вас что то посчитать в этом файле - что то найти ...

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

Постановка немного абсурдна. Если вам "прилетел" файл - то пускай улетает обратно.
В продуктиве нет таких постановок. В противном случае если "очень нуна" и срочно - бородатый unix-сисадмин
возьмёт grep/sed/awk/find и найдет вам всё что нужно за приемлемое время. Если
мощи утилит не хватит - то напишет на perl-е парсер. Всяко это будет быстрее чем
делать в Java (Java проект - очень дорого стоит если стартовать его с нуля для
подобных Превед-Медвед-миров). Кстати это (perl) должно быть отправной
точкой при бенчмарках. В противном случае можно еще и усомниться в целесообразности
Java вообще в подобной задаче.

...

Рейтинг:

0 / 0

18.02.2014, 13:38

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564537

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

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

Мною написанный парсер явно на JIT-компиляторе не компилировался. С учетом появившегося в 1.5 (не знал) class-data-sharing, любая сферическая реализация на стандартных классах в вакууме должна быть быстрее

В продакшене, при загруженной системе и включившимся JIT-компиляторе, самопалный парсер должен ООП уделывать /надеюсь ))) /

Плюс мониторинг/настройка JVM: память (раз в нее закачиваются больше объемы), JIT.
====
Задача поставлена сферически. Загнать файл (неизвестного объема!!!) в дебильную структуру в памяти. При дебильном формате файла (текст, х.з. что с кодировками, в задаче не уточнено).

Нужна скорость, тогда в первую очередь:
1. Нормальный алгортм (для описанной задачи: пройтись один раз по файлу, разпарсить и обработать, сохранять в памяти и никакие LinkedList'ы даром не нужны).
2. Нормальные форматы хранения в памяти и на диске
3. Нормальная постановка, упрощение задачи. Универсальность решения VS самопал. Не универсально, но быстро.

IMHO & AFAIK

...

Рейтинг:

0 / 0

18.02.2014, 14:03

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564550

mayton

Участник

Откуда: loopback

Сообщения: 53 422

Рейтинг: 2 / 0

Коллеги выкинтье из головы вообще все Arrays, Lists и вообще коллекции! У вас
любая задача почему-то вырождается в Стебелёк! Занахрена
вам вообще в памяти Java нужны эти гигбайтные списки и массивы? Что с ними
дальше будете делать?

...

Рейтинг:

0 / 0

18.02.2014, 14:08

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564554

ivanra

Гость

LinkedList тут действительно не в тему - фичи, на которых он имеет преимущество (вставка и удаление в середине списка), по крайней мере, в приведенном коде, не используются. А вставка в конец и у ArrayList достаточно оптимально сделана, тем более, что можно сразу место зарезервировать, ориентируясь на размеры файла.

...

Рейтинг:

0 / 0

18.02.2014, 14:10

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564612

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Для примера, создание и вставка 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

...

Рейтинг:

0 / 0

18.02.2014, 14:37

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564789

wst

Участник

Сообщения: 177

Рейтинг: 0 / 0

А дальше-то что с данными происходит? Если только просмотр-анализ можно же просто прочитать весь файл одной длинной строкой.

...

Рейтинг:

0 / 0

18.02.2014, 16:08

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38564797

Озверин

Участник

Откуда: Ростов-на-Дону

Сообщения: 3 646

Рейтинг: 0 / 0

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.

public static void main(String[] args) throws IOException, Exception {
     long time = System.currentTimeMillis();
        List<String> lines = Files.readAllLines(Paths.get("stat.txt"), Charset.forName("UTF-8"));
        System.out.println(lines.size());
     long t1 = System.currentTimeMillis() - time;
     System.out.println(" read file " + (t1) + " ms");
  }

С++ 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

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unordered_map>
#include <string>
#include <stdint.h>
#include <vector>
#include <sys/time.h>
#include <list>


#define BUF_LINE_SIZE	2048

int main( int argc, char ** argv )
{
	std::vector<char *> lines_list;
	std::vector<char *>::iterator lit;
	FILE * fp;
	char line[BUF_LINE_SIZE];
	char * cptr;
	unsigned long linescount = 0;
	struct timeval t1, t2;
	uint64_t mscount;

	if ( 2 != argc )
	{
		printf( "usage: testp1 <infile>\n\n" );
		return 1;
	}

	fp = fopen( argv[1], "r" );
	if ( ! fp )
	{
		printf( "can't open file %s for read\n\n", argv[1] );
		return 2;
	}

	gettimeofday( &t1, 0 );

	for ( cptr = fgets( line, BUF_LINE_SIZE, fp ); cptr; cptr = fgets( line, BUF_LINE_SIZE, fp ) )
	{
		lines_list.push_back( strdup( cptr ) );
		++linescount;
	}
	gettimeofday( &t2, 0 );
	fclose( fp );
	mscount = (t2.tv_usec + (((uint64_t)t2.tv_sec)*1000000ULL))
		- (t1.tv_usec + (((uint64_t)t1.tv_sec)*1000000ULL));
	printf( "done, result %lu lines at %llu.%06llu seconds\n\n"
		, linescount, mscount / 1000000ULL, mscount % 1000000ULL );

	for ( lit = lines_list.begin(); lines_list.end() != lit; ++lit )
	{
		free( *lit );
	}
	return 0;
}

Я может чего то не понимаю, как bufferedreader может быть быстрее filechannel? Вы не ошиблись?

...

Рейтинг:

0 / 0

18.02.2014, 16:10

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38565261

Atum1

Участник

Откуда: СПБ

Сообщения: 1 847

Рейтинг: 0 / 0

ОзверинЯ может чего то не понимаю, как bufferedreader может быть быстрее filechannel? Вы не ошиблись?

filechannel быстрее bufferedreader . (кажется по ссылке что я указал это как раз и описано )

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

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

сразу обрабатывая текущую строку и переходя на след. не создавая буферов, массивов строк , коллекций итд ...

будет ли это быстрее?

...

Рейтинг:

0 / 0

18.02.2014, 22:28

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38565285

mayton

Участник

Откуда: loopback

Сообщения: 53 422

Рейтинг: 2 / 0

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.

...

Рейтинг:

0 / 0

18.02.2014, 23:01

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38565301

Leonid Kudryavtsev

Участник

Сообщения: 9 300

Рейтинг: 0 / 0

Самое интересное, что попытка в своем классе сделать простейший конечный автомат дает ужасную производительность. При этом все стопориться на if... или на switch....

Добавление даже одного if в код, тут же посимвольную обработку _резко_ замедляет (((

Теоретически, вроде все понятно. Практически, за 2-а дня я на самодельном конечном автомате только достиг скорости исходного алгоритма (правда при _значительно_ меньшем потребности к выделению на куче и к GC) при значительно большей простоте алгоритма (минус все преобразование символов, никаких StringBuilder'ов).

В общем JIT-компилятор штука загодочная. Несмотря на то, что -XX:+PrintCompilation и -XX:+PrintInlining уверяют, что весь код откомпилирован. Рантайм библиотеки работают быстрее (или так же) самопального конечного автомата.

Хотя... это теоретически... практически задача ИМХУ - сферический конь в вакууме.

Чем скорость решения со split автора не устраивает - не понятно. Хотя, у него скорее всего вообще все на GC может стоять колом. У меня за 1.8-2 сек файл в 844 Mb парсится (без сохранения в LinkedList, только до String[])

...

Рейтинг:

0 / 0

18.02.2014, 23:35

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38565319

mayton

Участник

Откуда: loopback

Сообщения: 53 422

Рейтинг: 2 / 0

Думаю что здесь уже нельзя достичь больше производительности по той простой
причине что мы играем по правилам реализации java.lang.String. Можно было-бы
читать byte[] договорившись что рассматриваем single-byte encoded file но
на выхлопе не сможем получить String. Или сможем но опять будет трансформация
кодировки со всеми накладными расходами.

...

Рейтинг:

0 / 0

19.02.2014, 00:01

| Ответить | Цитировать | Написать

Быстрое чтение и разбор файла

#38565416

Alex Kuznetsov

Участник

Откуда: Ростов-на-Дону

Сообщения: 1 795

Рейтинг: 0 / 0

maytonДумаю что здесь уже нельзя достичь больше производительности по той простой
причине что мы играем по правилам реализации java.lang.String. Можно было-бы
читать byte[] договорившись что рассматриваем single-byte encoded file но
на выхлопе не сможем получить String. Или сможем но опять будет трансформация
кодировки со всеми накладными расходами.Без понимания того, в какой кодировке приходит файл, как он затем должен быть обработан и что впоследствии должно получиться, действительно можно гадать о том как улучшить производительность.
Вполне может статься, что данные приходят в Win1251 кодировке, поэтому просто byte[] чтение с приведением к char[] вполне может решить исходную задачу.
Но это как говорится только автору известно.

...

Рейтинг:

0 / 0

19.02.2014, 07:22

| Ответить | Цитировать | Написать

25 сообщений из 158, страница 2 из 7

все

Форумы / Java [игнор отключен] [закрыт для гостей] / Быстрое чтение и разбор файла

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=59&msg=38564470&tid=2123129]:	0ms
get settings:	6ms
get forum list:	9ms
check forum access:	2ms
check topic access:	2ms
track hit:	102ms
get topic data:	5ms
get forum data:	1ms
get page messages:	36ms
get tp. blocked users:	1ms
others:	197ms

total:	361ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы