Java.Help

[Hamster]

Да вся проблема в этом файлике. Дело в том, что чтобы посоветовать свои дурные мысли, их нужно проверить на практике. Итак, удалось создать текстовый файл, максимум 322 Мб и натыкать туда хз сколько бугаг. (Вот почему я и просил файл)

jdk 1.6 /Win7

Использование паттернов - довольно не "легкая" штука.
Твой код у меня выполнился за 8,5 сек
Удаляя все, что связано с паттернами и изменяя строчку :

public class Test {
    public static void main(String[] args) throws IOException {
	long start = System.currentTimeMillis(); // start timing
        BufferedReader reader = new BufferedReader(new FileReader("d:/www.log"));
        String line;
        int c = 0;
        while ((line = reader.readLine()) != null) {
			if (line.indexOf("Bugaga")>=0)
                c++;
        }
		long stop = System.currentTimeMillis(); // stop timing
		System.out.println("TimeMillis: " + (stop - start)+":   sec: "+(stop - start)/1000.0+"  bugag: "+c); 
    }
}

java Test
Process started >>>
TimeMillis: 4121: sec: 4.121 bugag: 421
<<< Process finished.

Почему бы не побаловаться с классами пакета nio...

class Test2{
	public static void main(String[] args) throws IOException {
        long start = System.currentTimeMillis(); // start timing
        ReadableByteChannel fc = Channels.newChannel(new FileInputStream("d:/www.log"));
        int c = 0;
        ByteBuffer buf =  ByteBuffer.allocate("Bugaga".getBytes().length*1000);
        while(fc.read(buf)>=0){
           CharBuffer cbuf = Charset.forName("cp866").decode((ByteBuffer)buf.flip());
           buf.clear();
           if(cbuf.toString().indexOf("Bugaga")>=0 ){
                c++;
           }
        }
		long stop = System.currentTimeMillis(); // stop timing
		System.out.println("TimeMillis: " + (stop - start)+"   sec: "+(stop - start)/1000.0+"  bugag: "+c); 
    }
}

java Test2
Process started >>>
TimeMillis: 3435 sec: 3.435 bugag: 421
<<< Process finished.
Здесь результат чисто зависит от объема буфера. Его нужно оптимально подобрать. (Особо с ним не игрался, но при коэффициенте 2500 уже идет возрастание времени).
У меня бугаги находятся между собой дальше, чем объем буфера, поэтому тут нада не профтыкать. но это уже мелочи.

Вот так от 8,5 до 3,4. А может можно еще быстрее?:?

 

[dreamer]

Удаляя все, что связано с паттернами и изменяя строчку

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

 

[GrAndSE]

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

Ну тут есть целых две проблемы:
1. Работа со строками в java вообще оставляет желать лучшего.
2. Юникод. Насколько мне известно добавление оного в движек того же php для регулярок замедляет работу где-то в два раза.

 

[akl]

try {
                String ps = "30.11.2009 13:45:54";
                Date md = java.text.DateFormat.getInstance().parse(ps);
                long tm = md.getTime();
                System.out.println(tm);
} catch (Exception e){}

Вывод - 1259581500000
При том, что

Date d = new Date();
d.getTime()

Получаю 1259601679944

Куда деваются секунды в первом случае?

 

[dreamer]

try {
                String ps = "30.11.2009 13:45:54";
                Date md = java.text.DateFormat.getInstance().parse(ps);
                long tm = md.getTime();
                System.out.println(tm);
} catch (Exception e){}

Вывод - 1259581500000
При том, что

Date d = new Date();
d.getTime()

Получаю 1259601679944

Куда деваются секунды в первом случае?

Если вы RTFM, то наверняка заметите, что getInstance возвращает парсер для короткого формата и что, цитирую

For example, SHORT for "h:mm a" in the US locale.

Т.е. формат не предусматривает секунд.

 

[akl]

Да, юзаю теперь ru locale. + getDateTimeInstance()

 

[akl]

По поводу работы со строками, недавно нашел:

You must be registered for see links

A rope is a high performance replacement for Strings. The datastructure, described in detail in "Ropes: an Alternative to Strings", provides asymptotically better performance than both String and StringBuffer for common string modifications like prepend, append, delete, and insert. Like Strings, ropes are immutable and therefore well-suited for use in multi-threaded programming.

You must be registered for see links

 

[Hamster]

Мягко говоря, до свинга тебе еще далековато. Начни с Code Convention.

 

[akl]

Прикольно получилось после удаления сообщений.
Hamster, спасибо, почитаю

 

[Пух]

Мне нужно написать 2 сортировки и узнать какая из них будет быстрей работать. Для этого нужно измерить скорость сортировки.

    public static void main(String[] args) {
        int [] a = new int [1000000];
        Random rand = new Random ();

        for (int i = 0; i < a.length; i++){
            a[i] = rand.nextInt(7000);
        }

        long start = System.nanoTime();
        qsort(a);
        long time = System.nanoTime() - start;
        System.out.println("time = " + ((double)time / Math.pow(10,9)));
    }
}

неужели массив с 1млн чисел сортируется за time = 0.10153949 seconds?
я вообще правильно подсчитываю время выполнения? Сколько раз нужно прогнать сортировку, что бы уменьшить погрешность ?