Myslel jsem v tom uz mame jasno: takovouto optimalizaci je lepsi nechat na prekladaci.
K @Immutable: tuto anotaci zminuje jiz Brian Goetz a spol. v Java Concurrency in Practice z roku 2006. Jeji pouziti ma vsak i uskali: napr. String neni ciste immutable, protoze ma atribut, ve kterem si uklada hashCode. Hodnota toho atributu je na zacatku 0 a pri prvnim volani hashCode() se zmeni. Nicmene jako pomucka pro vyvojare by @Immutable uzitecne bylo. U optimalizaci bych vsak byl opatrnejsi, protoze vetsinu zde zminenych optimalizaci dela JIT a ne javac. Z.T. -- Zdenek Tronicek FIT CTU in Prague Pecinovský Rudolf napsal(a): >> Typicky priklad na to, kdy muze runtime podobne optimalizace delat jsou >> operace bez sideefectu. ... > > Pořád jde o to, jestli mám optimizovat já nebo překladač. > > Když budu optimalizovat já, musím neustále hlídat, jetli se nezměnily > podmínky, které mi danou optimalizaci umožní. Nechám-li to na překladači, > nemusím hlídat nic. Při vhodně napsaném programu by dobrý překladač mněl > poznat, že v daném případě je zkrácené vyhodnocováné méně efektivní a lze > je nahradit. > > Abychom mu pomohli, bylo by užitečné, kdyby Java zavedla anotaci > @Immutable, po níž by překladač zkontroloval, že instance touto anotací > označeného datového typu jsou opravdu neměnné, a pak by této znalosti mohl > při nějakých následných optimalizacích využít. > > > __________ Informace od ESET NOD32 Antivirus, verze databaze 5336 > (20100803) __________ > > Tuto zpravu proveril ESET NOD32 Antivirus. > > http://www.eset.cz > >
