Dne 1. srpna 2010 10:43 Zdeněk Troníček troni...@fit.cvut.cz napsal(a):
Oto Buchta napsal(a):
b) trošku mi to připomíná schizofrenii jednoho známého webdesignéra.
Dostal za úkol vyvinout velkou JavaScriptovou aplikaci. Vyvíjel ji na
MACovi a safari a za pár měsíců byla téměř hotová. Chybělo
We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil.
Pokud to totiz clovek zabali hned po zjisteni vysledku, nemuze se
nikdy dobrat neceho lepsiho. Ono totiz dopredu vedet, ze se souhrn
vsech optimalizaci nedosahne lepsich
Dne 1. srpna 2010 16:13 neme...@gmail.com napsal(a):
Se nam to trochu zvrhlo. Z puvodny otazky proc je neco rychlejsi nez neco
jineho, tu mam otazku typu, proc to chces vlastne vedet
Takze pro uprseneni proc se na to ptam. Nejsem puvodni Ceckar, ba naopak. S
Ceckari ale hodne pracuji a ty
Dne 2. srpna 2010 13:50 Vaclav Stumbauer stum...@gmail.com napsal(a):
We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil.
Pokud to totiz clovek zabali hned po zjisteni vysledku, nemuze se
nikdy dobrat neceho lepsiho. Ono
Oto Buchta napsal(a):
We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil.
Prestoze je tento citat o necem malinko jinem, presto s nim
nesouhlasim. Presto si samozrejme mnoho z vas spolu s Cimrmanem rekne:
Je mozne, ze se vam
Oto Buchta napsal(a):
Tato debata presne ukazala, ze lide se deli na profileristy a
premyslivce (pozor, ani jedno neni mysleno hanlive!).
Typicky profilerista odpovi o zbytecnosti male optimalizace, o
dulezitosti zachovani citelnosti kodu, nutnosti overit i jinde (jine
JVM, stroj, , GC ci
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
