Tech, szoftvertervezés és programozás

Szoftverfejlesztés, Shaderprogramozás, DirectX

  • A betűméret növelése
  • Alapértelmezett betűméret
  • A betűméret csökkentése
NyisztorKaroly.org

6 ezredmásodperc - avagy mikor optimalizáljunk?

E-mail Nyomtatás PDF
Olvasóink értékelése: / 3
ElégtelenKitűnő 

Sebességre optimalizálni egy szoftvert érdekes, ugyanakkor nem mindig egyszerű feladat. Számos elméletet, érdekes cikket és vitát láttam már a témában.

Egyesek azt állítják, hogy manapság szinte fölösleges sebességre optimalizálni, hiszen a modern fordítók elég intelligensek ahhoz, hogy gyors futtathatót generáljanak, és előfordulhat akár az is, hogy ilyen célú törekvéseink éppenséggel szuboptimális eredményt produkáljanak. Mások azt vallják, hogy hiba túl korán optimalizálni. És vannak, akik szerint az optimalizálást mindig szem előtt kell tartani, és célzottan ellenőrizni a kódunk teljesítményét, a fejlesztés teljes ciklusa alatt.

Véleményem szerint az optimalizálást már akkor el kell kezdeni, amikor a rendszerterv elég kiforrott, és a főbb szolgáltatásokat stabil alapokra lehet fektetni. Ergo amint valami már elkezd működni, és várhatóan nem kell az egészet újratervezni. A választott módszertantól függ, hogy ez mikor következik be: a vízesésmodellnél valószínűleg korábban, de egy jól megvalósított agilis módszernél is viszonylag korán el kell érni ezt az állapotot.

Bővebben...
 

[Obj-C] Delegate ellenőrzése vs respondsToSelector

E-mail Nyomtatás PDF

Egy code review során felmerült a kérdés, hogy miért ajánlott a delegate ellenőrzése - avagy miért jobb az alábbi verziók közül a második?


if ([delegate respondsToSelector:@selector(baz:)]) 
{
    ...
}

helyett miért használjuk inkább ezt a formát:

if (delegate && [delegate respondsToSelector:@selector(baz:)]) 
{
    ...
}

Feleslegesnek tűnhet a második esetben a delegate érvényességének vizsgálata, hiszen a respondsToSelector nil-re úgyis false-t ad vissza. Azonban ez nem ilyen egyszerű: a respondsToSelector: végrehajtása során előbb meghívásra kerül az objc_msgSend metódus, amely az üzenetküldésért felelős; valami hasonló történik:

objc_msgSend( object, selector, ... )
{
    if( object == nil )
    {
        return;
    }
    else
    {
       // végrehajtás
       ...
    }
}

Tehát mindenképp megtörténik a delegate ellenőrzése, de előbb egy dinamikusan linkelt library metódus kerül meghívásra. Azzal, hogy előbb leellenőrizzük a delegate-et, ezt megspróroljuk => optimalizálás.

 

iOS hátterek

E-mail Nyomtatás PDF

iOS Linen Background iOS keresztmintás hátterek ajándékba (2560x1440 és 1920x1440):

 

Mac hibernálása

E-mail Nyomtatás PDF

Alapbeállításban a Mac Sleep hatására (Mac -> Sleep vagy Cmd - Option - Eject) nem áramtalanítja a RAM-ot, hogy megtartsa a tartalmát.
Emiatt asztali gépeken Sleep után egy áramtalanítás adatvesztéssel jár, laptopok* esetében pedig gyorsabban merül az akkumulátor (esetleg forrósodhat a látszólag kikapcsolt gép).
*Hordozható Mac-ek esetében az alapbeállítás (hibernatemode = 3, lásd lejjebb) garantálja, hogy az akkumulátor lemerülése után sem vész el az adat, mivel a memória tartalma kimentődik a merevlemezre is.

Az aktuális állapot lekérdezéséhez a következő parancsot kell beírni a terminal-ba:

Bővebben...
 

Memóriabővítés parancssorból (Mac)

E-mail Nyomtatás PDF

RAM-ból sosem elég, és Mac-en sincs ez másképp.

A következőkben be szeretnék mutatni egy egyszerű trükköt, amivel gyorsan szabad memóriához juthatunk.Azonban előtte kitérnék egy gyorstalpaló erejéig a Mac OS X memóriakezelésére, mert elsőre nem annyira egyértelmű.

Az alábbi screenshotok az Activity Monitor alkalmazás Rendszermemória fülét mutatják (egy 2008-as, 2GB RAM-mal rendelkező, OS X Snow Leopard-ot futtató iMac-en, valamint egy 2011-es, 8 GB RAM-mal felszerelt, OS X Lion alapú iMac modellen):

A memóriát az OS X 4 csoportba osztja:

Bővebben...
 


JPAGE_CURRENT_OF_TOTAL