[Java lista] for: ++i vagy i++

[Rákos Attila]

iklc> 3.1 Nem kell optimalizálni, a felhasználó teljesen vidám és
iklc> elégedett azzal, amit kapott.
iklc> 
iklc> 3.2 Nem kell optimalizálni, a felhasználó nem panaszkodik a
iklc> sebességre.

Igazából tényleg ez az egyik fontos dolog, ami az optimalizálásnál
számítana, hogy egyáltalán szükség van-e rá és megéri-e az
energiabefektetést. Hiába optimalizálok agyon egy kódrészt és töltök
el vele órákat, napokat, hogy akár 50x gyorsabban fusson le, ha az
eredeti 5 századmp és az optimalizált 1 ezredmp közti különbség a
felhasználó számára érzékelhetetlen. Ez persze programtól és
feladattól függ, de valóban mindenképp csak akkor érdemes nekiállni
komolyabb optimalizálásnak, ha problémát okoz a sebesség. Ez az i++ és
++i dolog több más hasonlóval együtt szerintem olyan dolog, aminek
vmikor 15-20 éve még lehetett jelentősége akár a napi feladatokban is,
de mára csak afféle örökölt hagyomány az akkori időkből, ami szájról
szájra, régi programozóról új programozóra terjed, de a mai
gépteljesítmények és fordítóprogramok mellett kivételesen ritka
esetben kell ilyen szinten bitfaragni.

 Attila

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From:    istvan.ketler at lhsystems.com <istvan.ketler at lhsystems.com>
To:      javalist at javagrund.hu <javalist at javagrund.hu>
Date:    Monday, February 9, 2009, 8:58:55 AM
Subject: [Java lista] for: ++i vagy i++
--====----====----====----====----====----====----====----====----====----===--
Sziasztok,

nagy figyelemmel és kíváncsisággal olvastam végig most hétfő reggel az összes $subject emailt. Kicsit elgondolkodtatónak tartom, hogy 20+ üzenet is elment, mire végre valaki megemlítette, hogyan is kell optimalizálni...

A tárggyal kapcsolatban az állításom az, hogy mindegy, melyiket használod. A fordító, esetleg a JIT compiler nagy eséllyel úgyis kioptimalizálja (bezony, amennyire t'om, a JIT Compiler is képes felismerni néhány patternt).

Szerintem az optimalizált kód írásának lépései a következők.

1. Adj "versenyképes fizetést" az architektednek, hogy jót kapj, aki tervezés szintjén hatékony modulszerkezetet és feladat-allokációt talál ki neked. Ha magad vagy az architekted, akkor is fontos a jó fizetés == (még) nagyobb motiváció! :)

2. Írj minél világosabb, áttekinthetőbb kódot. Pl. használd vagy az i++, vagy a ++i formát MINDIG, hacsak jó indokod nincs épp az adott ponton a "másik" használatára. (Nem, a "mert itt szerintem gyorsabb", az nem egy jó indok. Hinni máshol kell, mi állítólag mérnökök vagyunk, nem elhisszük a dolgokat, hanem megmérjük, kiszámoljuk, megtervezzük.)

3. Amikor a kódod műxik, megkezdheted az optimalizálás subtaszkot. Ennek lépései:

3.1 Nem kell optimalizálni, a felhasználó teljesen vidám és elégedett azzal, amit kapott.

3.2 Nem kell optimalizálni, a felhasználó nem panaszkodik a sebességre.

3.3 Ha már ennyire optimalizálni akarsz, végezz méréseket. Ezek segítségével megtudhatod, hol tölti a program ideje nagy részét.

3.4 A mérési eredmények által kritikusnak mondott részeket próbáld meg *az architekttel együtt* áttervezni. Nem a kódot birizgálgatni - áttervezni!

3.5 Implementáld le a javítást, végezz méréseket. Ha szerinted javult a program, akkor goto 3.1, egyébként 3.4.

3.6 Ha más gépre (főleg processzorra) viszed át a programodat, kezdd elölről az egészet.

Azon agyalni, hogy i++ vagy ++i, szerintem egyszerűen értelmetlen. Optimalizál a fordító, Java esetén a JITC, de még a hardver is optimalizál (hogy is kell betűzni azt hogy pájplájning?). Hogy mi lesz a kódodból a végén, azt soha az életben meg nem jósolhatod ma már.

Sokkal, de sokkal nagyobb súllyal esik latba az, hogy mennyire sikerült jól a design. Ha ott elböktél valamit, akkor szórakozhatsz a pre/post inkrementálással amennyit akarsz, a program vacak marad. Az áttekinthető, érthető kód is sokkal többet számít.

S hogy az idézett levélre is válaszoljak, szerintem bizony a fordító dolga, hogy optimalizáljon. Ha nem végez elég jó munkát, akkor esetleg jöhet a mérés, és az ezt követő optimalizálás. Szükség viszont csak ritkán lesz rá. A szürkeállományt meg ha lehet, ne vesztegessük jórészt mechanikus munkára, inkább használjuk alkotó munkára (pl. tervezés).

Üdvözlettel,

Iván

István Ketler
Project Coordinator
 
Lufthansa Systems Hungaria Kft.
Airline Management Solutions
Schedule & Revenue Management
Alkotás u. 53.
1123 Budapest
Hungary
 
Tel: +36 1 887-2815
Fax: +36 1 887-2977
 
Room: MOM Park, Building A, Room 556
 
e-mail: istvan.ketler at lhsystems.com
Internet: www.LHsystems.hu
 

> 
 
Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria Kft, Budapest, Fövarosi Birosag 01-09-463417
Geschaeftsfuehrung / Management Board: Monika Houck

-----Original Message-----

> From: javalist-bounces at javagrund.hu 
> [mailto:javalist-bounces at javagrund.hu] On Behalf Of eMeL
> Sent: Sunday, February 08, 2009 6:56 PM
> To: javalist at javagrund.hu
> Subject: Re: [Java lista] for: ++i vagy i++
> 
> 
> > Szerintem meg gondolkozzon rajta a fordító.
> 
> Ha mindig a fordító gondolkozna, akkor félművelt programozók 
> is elegendőek lennének ;)
> 
> Bizonnyára van eset (természetesen jól összetett, amit a 
> kolléga részletezett), amikor már nem csak optimalizálás, 
> hanem komoly működési különbség van a prefix és postfix 
> között... szóval ebben a szakmában egy darabig még kell a 
> szürkeállomány is ;)
> 
> Ettől függetlenül, szerintem ma már minden fordító van olyan 
> okos, hogy kioptimalizál ilyesmit, szóval csak azért nem kell 
> programozási stílust váltani ;)
> 
> eMeL
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
> 
_______________________________________________
Javalist mailing list
Javalist at javagrund.hu
http://javagrund.hu/mailman/listinfo/javalist
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=