Ho4u obsuditь vopros uvili4enie proizvoditelnosti koda. Vsem izvsetno 4to:
a+=1 4em a=a+1
StrinBuffer vmesto konkatencii strok.
Objedinenie neskolkih uslovij v odnom if 4em v 2 i bolee.
Kakie eshjo estь sposobi ?

P.S.
Po4emu trasnlit ne rabotaet   ???

Это сообщение отредактировал(а) Tony - 2.1.2008, 17:36

разве это увеличивает скорость?!

Добавлено через 28 секунд
a++ наверно?

Добавлено через 1 минуту и 55 секунд
умножение на число в степени двойки.

x * 2 == x << 1
x * 4 == x << 2
x * 8 == x << 3

Добавлено через 8 минут и 49 секунд
вот вообще классная статейка по баловству с битами

Da,tut ne uda4no privjol nadobilo 


V ru nete bila statja pro java i kak povisit' proizvoditelnost' No ssilki ne pomnju :(

Это сообщение отредактировал(а) Tony - 2.1.2008, 18:24

Ловля "блох". Компилятор, наверняка, сам справляется с такого рода оптимизациями. 

да, пожалуй, но с битами, всё-таки думаю нет ^_^

И с битами в том числе. Многое ещё зависит от конкретной архитектуры, от того, будет ли данный кусок java-кода скомпилирован и на каком этапе (и каким образом, конечно). 

Для справки - на моём компьютере java-код x & 1 не будет работать быстрее, чем x % 2.

При ручной оптимизации стоит обращать внимание только на минимизацию обращений к памяти, всё остальное не стоит внимания. Да и это уже - гадание на кофейной гуще - целевая jvm не известна. Ведь при работе на каком-нибудь процессоре, где вообще нет разницы в скорости для разных арифметических операций вся эта работа коту под хвост. А ведь вполне можно нарваться на такой, где наоборот - умножение и деление будет работать много быстрее битовых операций. Так что не стоит, не стоит 

Это сообщение отредактировал(а) w1nd - 3.1.2008, 23:37

Nu kak ja ponimaju, boslhe ne kakih soobrazhenij net  ?

w1nd, вы статейку почитайте, там более сложные операции, чем операции с умножением и делением.



на самом деле, договориться можно до многого, вплоть до того, чтобы выбрать native язык, так скорость вообще возрастет ^_^
Как мне недавно на форуме ответили "Это не наши методы" ©

Добавлено через 11 минут и 9 секунд
С другом разрабатывали шахматы недавно в рамках лабораторной работы. Первая версия ИИ была очень тормозящая и менее умная. Сначала думали, что проблема в том, что шахматы хранятся массиве а не в векторе (разница, что использовать в нашем случае была), ИИ делал массовые операции, поэтому считается, что оптимизация уместна.
Попробовали, сделали... результат тот же, со временем совершенствовался ИИ, применялись новые подходы, в итоге ИИ в конечной версии бегает шустро, почти мгновенно, вот и думайте, стоит ли ломать спички, когда собака зарыта в подходе ^_^

А по теме вот еще ссылочка: http://lib.juga.ru/article/view/164/1/68/
И хорошее начало:

В кроссплатформенной среде оптимизация кода под конкретную архитектуру (процессор/ОС/jvm) бессмысленна и вредна. Поэтому для java ничего подобного не читал, впредь не собираюсь и другим не советую 

Это сообщение отредактировал(а) w1nd - 6.1.2008, 07:59

Наконец нашел в сундучке запылившуюся тему, Сдуем пылинки
Вернемся к нашим битам.
Скажите, уважаемый w1nd, если под архитектуру подстраиваться не стоит, то как же объяснить, к примеру, работу метода Integer.getChars()
где изобилируют строки типа 

+1 Современные компиляторы делают такие вещи намного лучше простых смертных программистов. Это становится понятным, если послушать приличный университетский курс по оптимизирующим компиляторам. Ну, или Ахо почитать (как раз новенький вышел).

Лучше читайте руководства по тюнингу JVM — здесь намного большего достичь можно.

Правда, пробегало что-то в ru_java про оптимизацию хранения примитивных типов в коллекциях (действуя в лоб, их же в объекты заворачивать нужно): есть какие-то такие наработки. Но конкретней не скажу.