[elektro-etc] Azure

[vajk fekete]

ha mar belemegyunk: 
 - az if kiertekelese is eroforrasigenyes. ha gyakran nemnulla az ado, akkor ezen tobbet bukunk, mint nyerunk.
 - a program merete nott, a memoria is eroforras
 - ha egyszer valakinek ezt olvasnia kell, netan modositania vagy javitania, akkor tovabb tart, es a melos ideje is eroforras

vajk


________________________________
 From: Acs Gabor <agabor at electrodesign.hu>
To: elektro-etc at tesla.hu 
Sent: Thursday, 1 March 2012, 13:58
Subject: Re: [elektro-etc] Azure
 
Ezen gondolkoztam én is, aztán arra jutottam, hogy a formátumból ítélve ez a programnyelv/felhasználás nagyon nem erről az erőforrás-takarékos szemléletről szól -gyakorlatilag nekik mindegy.

Szóval az is számít, hogy 8 bites MCU-ra, vagy 3GHz-es PC-re fejlesztesz. Nekem pl. nagyon furcsa volt pár napja egy rendszer, 2mp.-enként kellett leolvasni egy kb. 15 karakteres kódot, de nem tököltek az olvasó beállítással, az folyamatosan küldte be a kódot, mondjuk 100-at másodpercenként. Azt mondta a fejlesztő, neki mindegy, van 2G RAM a gépben, meg SQL, majd leszűri. Én biztos vagy triggerelném az olvasást, vagy az olvasót állítanám, hogy csak akkor küldjön, ha változást érzékel. Egyik szemlélet ilyen, másik olyan.

Itt ebben az esetben az if kiértékelése is plusz idő, nagyon sarkos azt eldönteni, hogy milyen gyakorisággal van 0-ás eset, és ez alapján melyik éri meg jobban, a nullát potyára osztani (szerintem nem tart az olyan sokáig), vagy fölöslegesen if-eket csinálni.
De hamár If-et csinálunk, valszeg gyorsabb a 0, vagy nem 0 eldöntése, mint a >0 vizsgálata (bár lehet hogy fordítás után ugyanaz lesz)


Gábor

2012.03.01. 13:33 keltezéssel, Kovács József írta:
> ... és mi gyorsabb, ha gyakoribb az adómentes ág?
> 
> az if vagy a money*(1+tax/100) kiértékelése?
> akkor is mindenképpen, ha épp 0 a tax ?
> 
> Szerintem a fölösleges kiértékelés
> cirka 50-100X lassúbb lenne...
> 
> Főleg, ha az adott procin
> a  szám tárolási helye is
> nagyobb a szóhossznál!
> 
> KJ
> 
> 
> 2012.03.01. 13:04 keltezéssel, vajk fekete írta:
>> de vegyuk mar eszre, hogy a peldaban nem a zarojelek voltak a lenyeg, hanem az, hogy egy kulon iffel kulon kezelte azt az esetet, ha az ado 0, mikozben az altalanos keplet teljesen jol kezelte automatikusan.
>> 
>> ha en vagyok keptelen kommunikalni, es en nem vettem eszre a mondandot, akkor bocs.
>> 
>> vajk
>> 
>> 
>> ________________________________
>>   From: Kovács József<kj at faldeko.hu>
>> To: elektro-etc at tesla.hu
>> Sent: Thursday, 1 March 2012, 12:48
>> Subject: Re: [elektro-etc] Azure
>> 
>> 
>> 
>> 2012.03.01. 11:49 keltezéssel, potyo írta:
>>> 2012. március 1. 11:41 Kovács József írta,<kj at faldeko.hu>:
>>> 
>>>> 
>>>>       print round(money*(1+(tax/100)),2);
>>>>> 
>>>> 
>>>> ...és is szeretem így kirakni a zárójeleket.
>>>> Gondolkodjon a franc kód írás/olvasás közben a sorrenden.
>>>> 
>>>> A fordító úgyis kiszedi majd őket :-)
>>>> 
>>>> Neccesebb helyekre én is szeretem kirakni (pl. if (a&   (1<<b)) nem
>>> ugyanaz, mint if ((a&   1)<<b)), de azért egy összeadás-szorzás között meg
>>> lehet jegyezni a sorrendet. De mondjuk engem is a zárójel zavart a kevésbé,
>>> jobban zavart az, hogy az összes számításnál az adóra vonatkozó feltétel
>>> ott szerepelt és két ágra volt bontva minden. Ezt azért elárul egy képet a
>>> készítőjéről...
>> 
>> Előrelátást?
>> 
>> Nálam is hasonló a struktúra.
>> Gondolva a jövőbeni változáskora...
>> 
>> Így, ha nem csak két eset lesz akkor is
>> csak az elágazások száma nő meg és
>> minden eset külön-külön kezelhető.
>> A struktúra már müködik, tesztelt.
>> 
>> Nem kell pöcsölni egy egész új struktúra kitalálásával...
>> 
>> Ez az előre látás már bejött párszor.
>> 
>> Sőt az is lehet, hogy
>> Valaha más matek volt a két ágra!
>> Csak mostanra épp azonos lett...
>> 
>> Mellesleg, ha nem adós ág sokkal gyakoribb, akkor
>> fölösleges is lenne mindig a szorzás/osztásokat elvégezni
>> Nem igaz...?
>> 
>> KJ
>> 
>> KJ
>> 
> 
> 
> _____________ NOD32 6534 (20111011) Inform�ci� _____________
> 
> Az �zenetet a NOD32 antivirus system megvizsg�lta.
> http://www.nod32.hu
> 
> 
>