Mate pravdu, ale ja to v zadnem pripade nepovazuji za navod k optimalizaci! A Josh Bloch temer jiste take ne. Staci otevrit Effective Java a precist si radu 55. Mimochodem, na zacatku rady 55 je ten citat o 97% a take jeste dalsi dva. Tento je z roku 1975:
"We follow two rules in the matter of optimization: Rule 1. Don't do it. Rule 2 (for experts only). Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution." Volny preklad: Ve veci optimalizace se drzime dvou pravidel: Pravidlo 1. Nedelejte ji. Pravidlo 2 (pouze pro experty). Zatim - tj. dokud nebudete mit ciste a neoptimalizovane reseni - ji nedelejte. Tyhle citaty ukazuji, ze nektere veci jsou v programovani platne prekvapive dlouho. Skoda jen, ze nevime, ktere to budou. Z. -- Zdenek Tronicek FIT CTU in Prague Rastislav Rehak napsal(a): > A presne tu je ten pes zakopany - netreba rozmyslat nad tym co je > rychlejsie ( na urovni mikrokodu ), ale co je spravne. > && sa v 99% pripadoch pouziva prave na to , aby sa druha cast vyrazu > nevydnocovala vobec z dovodu : > - je to volanie dakeho zlozitejsie vyrazu alebo nebodaj lozenie do > databazy, disk a pod > - kladne vyhodnotenie prveho vyrazu je nutne , aby sa druhy vyraz dal > vobec vyhodnotit : person!=null && person.isValid() > > R > > Zdeněk Troníček wrote: >> Jak to Josh Bloch myslel nevim, ale ze & muze byt rychlejsi nez && me >> neprekvapuje. Pri pouziti & procesor muze vyhodnocovat operandy >> paralelne, >> zatimco u && musi pockat, jak dopadne vyhodnoceni prvniho operandu. >> Takze >> pokud jsou operandy nezavisle a procesor vicejadrovy, tak to bude mozna >> i >> docela caste. >> >> Z. >> >
