Mna napr. zaujala poznamka z keynotu Josha Blocha z terajsieho Java
Language Summitu:
In some circumstances it turns out that & is faster than && in Java,
because a && will short curcuit, which means it will branch. The single
ampersand will always execute both sides, which means the CPU can
pipeline both of them to execute at the same time.
Ale originalna prezentacia nie je este k dispozicii, takze nie je mi
celkom jasne, ako sa to myslelo.
RN
On 2. 8. 2010 20:57, Ondra Medek wrote:
Takze
kdyz se nekomu podari "mikrooptimalizace" typu "prochazeni pole odzadu je
rychlejsi", v dalsim buildu JDK uz to nemusi fungovat.
Ja bych jen doplnil konkretne k teto "optimalizaci": ono to nemusi byt
rychlejsi vzdy. Zalezi, nejen na JVM, ale i jaka data se prochazi,
typu cache a procesoru, a mozna dalsich faktorech. Tedy zrovna tato
optimalizace je IMHO obecne naprosto zbytecna.(Mne osobne se lepe ctou
for cykly od 1 do N.) Dobra je leda tak pro nejaky konkretni pripad,
kde se opravdu nameri zrychleni. Tim nechci spoustet flame na tema
rychlost prochazeni pole. Jen chci uvezt konkretni pripad, kdy je
takova mikrooptimalizace zbytecna.
Zpatky k tomu "instanceof": pouziva se to hojne v equals metodach,
tedy bych se o rychlost nebal. Pravdepodobne se v kazde aplikaci vola
tolikrat, ze nejake dalsi pridani uz nema vyznam. (kdyby to byla
nejaka brzda, tak by se jiste nasel nekdo, kdy by se snazil equals
implementovat jinak).
P.S. pro Otu: ja jsem take z HPC sveta.
