abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 08:00 | Nová verze
Před 15 lety, 1. října 1999, byla vydána první stabilní verze 1.0 unixového tiskového systému CUPS (Common Unix Printing System). Při této příležitosti vyšel CUPS 2.0.0. Přehled oprav a novinek v poznámkách k vydání.
Ladislav Hagara | Komentářů: 4
včera 23:03 | Zajímavý software
Byla vydána verze 0.6.0 multimediálního přehrávače mpv. Přehrávač mpv vychází z přehrávačů MPlayer a mplayer2. Rozdíly mezi přehrávači jsou uvedeny v dokumentaci.
Ladislav Hagara | Komentářů: 9
včera 15:19 | Zajímavý článek
Organizace Electronic Frontier Foundation (EFF) upozorňuje v rámci seriálu Stupidní patent měsíce (I, II) na společnost Blue Spike. Ta se během 14 dnů začala soudit hned s 45 společnostmi (Patent Blast). Prý porušují její 4 patenty US 7,346,472, US 7,660,700, US 7,949,494 a US 8,214,175. Patenty mají stejný název – Způsob a zařízení pro monitorování a analýzu signálů. Stejný je i abstrakt. Liší se jenom v nárocích. EFF na patentech ilustruje… více »
Ladislav Hagara | Komentářů: 9
30.9. 22:22 | Zajímavý projekt
Mozilla představuje na svém blogu Mozilla Hacks zaměřeném na vývojáře zařízení Matchstick s Firefox OS. Jedná se o otevřenou alternativu k Chromecastu. Otevřený je jak software, tak i hardware. Projekt lze podpořit na Kickstarteru. Matchstick lze objednat za 18 dolarů.
Ladislav Hagara | Komentářů: 1
30.9. 11:19 | Zajímavý projekt
V prosinci 2012 byl potvrzen linuxový port legendárního RPG Baldur's Gate (zprávička). Trent Oster před několika hodinami na Twitteru oznámil, že bylo na Steamu spuštěno testování Baldur's Gate: Enhanced Edition verze 1.3.
Ladislav Hagara | Komentářů: 50
30.9. 09:17 | Pozvánky
S novým semestrem se nám opět rozjíždí cyklus Androidích přednášek a setkání Android vývojářů aDev Meetups. Přijďte si ve středu 8. října v 18 hodin do budovy FIT ČVUT poslechnout přednášku od Jany Moudré o tom, jak se dá automatizovat testování uživatelského rozhraní. … více »
Gug.cz | Komentářů: 0
27.9. 22:02 | Humor
Dnes, 27.9.2014, slaví životní jubileum Larry Wall, jeden z největších programátorů historie. Evropské oslavy tohoto významného jubilea se konají dnes v obci Perl, která sousedí s městečkem Schengen na hranici mezi Sárskem a Lucemburskem. Laudatio pronesou pánové Guido van Rossum a Yukihiro Matsumoto. :-)
m-bi | Komentářů: 184
27.9. 12:24 | Nová verze
Vyšla OpenMandriva Lx 2014.1. Jedná se o opravné vydání OpenMandrivy Lx 2014.0 (zprávička). Opravuje 233 chyb. Řada balíčků byla aktualizována. Nejnovější OpenMandriva přináší Linux 3.15.10 (nrjQL), KDE 4.13.3, Firefox 32.0.3 nebo LibreOffice 4.3.1. Podrobnosti v poznámkách k vydání.
Ladislav Hagara | Komentářů: 11
26.9. 21:42 | Humor
Shellshock není jenom aktuální bezpečnostní problém v Bashi (zprávička). Již v březnu 2012 byla představena v Bashi napsaná vesmírná střílečka ShellShock.
Ladislav Hagara | Komentářů: 8
26.9. 12:22 | Pozvánky

Letošní ročník konference LinuxDays vám přinese 47 přednášek od zajímavých osobností nejen z linuxového světa, stánky velkých i malých projektů, stavbu 3D tiskáren, HPC workshop, občerstvení s dobrou kávou a hlavně setkání se zajímavými lidmi pohybujícími se okolo otevřeného světa.

… více »
Petr Krčmář | Komentářů: 0
Hlasuji z:
 (81%)
 (13%)
 (3%)
 (2%)
 (1%)
 (1%)
Celkem 3977 hlasů
 Komentářů: 45, poslední 21.9. 11:10
Rozcestník
Reklama
Autoškola testy online Levný benzín

Správa paměti v Mac OS X

15.9.2009 20:30 | Přečteno: 3804× | Apple | Výběrový blog | poslední úprava: 15.9.2009 20:40

Správa paměti v Mac OS se dost liší od Windows, Linuxu nebo dokonce BSD a současně se dost obtížně shánějí relevantní informace na toto téma. Myslím, že tedy bude užitečné shrnout ve zkratce známá fakta a současně tím třeba i vyvrátit několik mýtů, kterými je celá záležitost opletena.

Nejdříve krátká odbočka k získávání detailních informací o jádře Mac OS. Jediným spolehlivým zdrojem je kniha Mac OS X Internals - A Systems Approach a i ta bohužel už trochu zastarala. Dále se dá občas něco pochytit od vývojářů, kteří metodou pokus-omyl nějaké informace zjistili. Doporučuji např. video přednášky jednoho z vývojářů VMWare Fusion (prvních 14 minut marketingových keců můžete směle přeskočit). Dokumentace od Applu je velmi povrchní, zavádějící, nepřesná a občas se vyloženě "míjí s pravdou". Situace je opravdu katastrofální, nesrovnatelně horší než v případě Linuxu nebo dokonce Windows.


Podívejme se na výstup vm_stat

Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free:                          79657.
Pages active:                      2440855.
Pages inactive:                     633605.
Pages speculative:                  650414.
Pages wired down:                   389994.


Čísla jsou v 4 kiB stránkách, ta potvornost nemá žádný přepínač, kterým by se dala přinutit ukazovat v jiných jednotkách. Free je prostě volná paměť, kterou je možno ihned použít bez jakýchkoliv dalších operací. Seznam volných stránek je uložen ve FIFO kontejneru, tedy ve frontě.


Speculative je volná paměť, která je naplněná přednačenými daty (v tomto případě téměř 2,5 GiB, nepodařilo se mi zjistit jaký mechanismus se používá ale nepředpokládám, že by se tolik místa zaplnilo prostým read-ahead přístupem. Navíc tato paměť hned po bootu prudce roste). Táto data byla přednačtená ale nikdy k nim nebylo přistoupeno, v takovém přsípadě by spadly do active/inactive kolotoče, o kterém za chvíli. GUI aplikace reportují volnou paměť jako součet free + speculative.


Wired paměť je zamknutá ve fyzické paměti- nelze ji odstránkovat. Je zde zejména paměť jádra ale běžný proces si o zamčení oblasti paměti voláním mlock může zažádat také (Linux má obdobné volání také, ve Windows lze správci paměti pouze doporučit aby nějakou oblast ponechal v paměti, není to však závazné a nelze s tím tedy počítat což má určité implikace pro realtime aplikace a aplikace, kde by případne odstrankování mohlo být bezpečnostním problémem. Ve windows je vlastně i podstatná část paměti jádra stránkovatelná... ale to je zase na jiný článek :-) ). Některé aplikace mlock používají, zejména Parallels a VMWare takto zamykají obrovské bloky paměti. Z výpisu výše je vidět takřka 1.5 GiB zamčené paměti protože tam běží ve VMWare stroj s přidělenou pamětí 1 GiB. Wired paměť má v Mac OS jednu specialitu - nevrací se po uvolnění ihned do free poolu ale stane se tak až když volná paměť dojde nebo množství wired paměti přesáhne nějakou hranici. Plyne to z maximálně líného přístupu ke správě paměti řídicího se heslem- pokud je volná paměť tak na nic nesahej. To je v ostrém kontrastu k „hyperaktivní“ správě paměti ve Windows. Linux je z tohoto hlediska někde uprostřed. Wired paměť nemá svoji frontu stránek a tyto stránky jsou pochopitelně vyřazeny ze všech jiných zde zmiňovaných front. Srovnejte teď co uvádí oficiální vývojářská dokumentace od Apple ( Applications, frameworks, and other user-level software cannot allocate wired memory. ) a jaká je realita např. pomocí tohoto triviálního prográmku


#include < stdlib.h>
#include < stdio.h>
#include < sys/mman.h>


int main(void) {
	int *i = (int*)calloc(1024,1024*1024);
	printf("%d\r\n",mlock(i,1024*1024*1024));
	getchar();
	return 0;
}

, který naalokuje 1 GiB paměti a zamkne ji a wired krásně povyskočí právě o 1 GiB nahoru.


Active je paměť která je mapovaná nějakým procesem. Je zde paměť anonymní (tedy paměť, která není svázaná s žádným souborem na disku, tedy vzniklá zejména voláním malloc nebo mmap s MAP_ANON flagem) i neanonymní. Seznam aktivních stránek je udržován ve frontě.


Inactive jsou stránky, které nejsou mapovány žádným procesem (většinou následkem toho, že správce paměti toto mapování odebral, o tom ale později). Existují dvě fronty „neaktivních“ stránek- pro anonymní a neanonymní stránky. Inactive stránky mohou být „špinavé“ (dirty stránky jsou takové, které je nutno zapsat na disk předtím, než mohou být odstraněny z paměti, pro anonymní paměť to znamená, že obsah stránky v paměti a ve swapu se liší případně stránka svůj obraz ve swapu doposud vůbec nemá).


Součet free, active, inactive, speculative a wired dá dohromady celou dostupnou paměť počítače (± pár stovek kiB, které popravdě nevím odkud se berou, že by čtení těch statistik nebylo atomické?), tedy v případě výše uvedeného příkladu 16 GiB. Jak vidíte ve výpisu vm_stat není žádná položka typu cache, buffers ani nic podobného. Mac OS si žádný přehled stránek tohoto typu nevede. Věci, které na Linuxu obstarává SLAB jsou rozpuštěny někde ve wired paměti a cache je zase rozeseta po active a inactive paměti.


Myšlenka je taková, že v active má být pracovní sada všech spuštěných procesu od jejich kódu přes knihovny až po data, nad kterými pracují (z každé z těchto oblastí samozřejmě jen stránky, které se využívají), inactive je oblast, použité paměti, která ale nepatří do současné pracovní sady ale existuje určitá pravděpodobnost, že bude znovu potřebná. Uměním je (někteří suchaři tomu říkaji heuristika ;-) ) zvolit poměr mezi active a inactive a algoritmus přehazování stránek mezi nimi tak, aby se minimalizoval počet zápisu a čtení stránek z/na disk. Jak je to tedy řešeno v MacOS?


Jak už jsem naznačil výše- správce paměti je v MacOS líný jak to jen jde. Když je volná paměť tak se stará jen o to, aby přiděloval volnou paměť (bere z free fronty a dává do inactive) procesům a po jejich ukončení vrátí anonymní paměť do free a neanonymní přesune do inactive pokud tam už není. Když proces sáhne na svojí stránku, která je v inactive paměti tak vyvolá soft page fault, stránka se přidá na konec active fronty. A to je vše.


Když volná paměť dojde (resp. klesne pod určitou úroveň, která se odvodí od celkové velikosti paměti) tak se teprve začne projevovat. Zjistí, zda není volná wired paměť a případně ji vrátí do free fronty. Následně začne přesouvat paměť z active do inactive fronty a to tak, že bere stránky ze začátku active fronty, odstraní její mapování v procesech a přidá je na konec inactive fronty. Nevyužívá se tedy žádný mechanismus stárnutí stránek resp. LRU, žádný zvýhodnění pro interaktivní/aktivní procesy ani nic podobného. Každá nezamčená stránka každého procesu se dříve nebo později dostane do jedné z inactive front.


Dále provádí čištění stránek v inactive frontě a bere stránky ze začátku inactive fronty a vyhazuje je z paměti. Opět se postupuje výlučněs principem FIFO. O samotné stránkování se pak stará několik specializovaných rutin (samostatně pro výměnu stránek mezi swapem a pamětí, mezi blokovým zařízením a pamětí, …). O vytváření souborů, do kterých se swapuje se stará samostatný proces (dynamic_pager), který se stará, aby se zaplnění swapovacích souborů pohybovalo v rozmezí nastaveném parametry high a low watermark.


Inactive a active fronty realizují jako celek algoritmus, kterému se přezdívá FIFO with second chance. Jinými slovy každá stránka někdy spadne do inactive ale než probublá inactive frontou až do stavu, že bude odstraněná má šanci, že když se znova použije tak se zařadí na konec fronty active.


Algoritmus je tedy relativně jednoduchý, důležité ale je jak se to v praxi chová. Když se dostane systém do úzkých tak začne nezadržitelně trashovat. Všechny procesy mají šanci se trochu projevit než probublají celým kolotočem front a žádný vyloženě nehladoví nicméně většina úsilí je stále vynakládaná na neustále odkládání a načítání stránek. Linux se svým swap tokenem je na tom podstatně lépe. V situaci, kdy se working set pohodlně vejde do paměti se projeví další vlastnost- velká ochota nahradit stránky chvíli nečinného procesu stránkami diskové cache. Jinými slovy- chová se to podobně jako Linux s velmi vysoko nastaveným parametrem SWAPINESS. Tento jev je opravdu velmi silný a dá se mu zabránít jen čtením souboru např. přes mmap s flagem MAP_NOCACHE (ten by se dost hodil i v linuxu ale to zase odbíhám) ale nikde se o tom pořádně nedozvíte a přečtením velkého souboru přes fopen a fread si vyhodíte z paměti běžící aplikace na úkor diskové cache.


Mac OS zkrátka zbožňuje paměť a z výše napsaného je myslím zřejmé proč tomu tak je :) K tomu navíc přispívá i to, že samotné jádro a základní aplikace pamětí příliš nešetří. Pokud sečtu RSS procesů kernel_task, mds, WindowServer, coreServicesd,... tedy takových, které jen zajišťují chod systému a grafického prostředí, na svém počítači tak se dostanu k úctyhodné hodnotě 1,7 GiB.

       

Hodnocení: 100 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

Jardík avatar 16.9.2009 00:43 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
Windows lze správci paměti pouze doporučit aby nějakou oblast ponechal v paměti, není to však závazné a nelze s tím tedy počítat což má určité implikace pro realtime aplikace a aplikace
Nesouhlasím, ve Windows můžete naalokovat fyzickou paměť a nic vám ji neveme.
Věřím v jednoho Boha.
16.9.2009 13:09 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

Oops, to jsem neznal, clovek se uc cely zivot :) Na druhou stranu tohle se asi neda v normalnim softu urcenem pro bezneho smrtelnika pouzit kvuli nutnosti nastavit prava.

 

17.9.2009 14:06 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

To je ale správné. Běžný programátor ani program by neměl tyhle akci vůbec umět. Na tu by měl sahat jenom ten, kdo ví co a proč to dělá.

Upřímně, čím méně hacků dovolí běžný desktopový systém, tím jenom lépe.

17.9.2009 17:01 Tom K | skóre: 20
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
Chcete říct, že "normální" SW by neměl se snažit, aby použité klíče nebyly k nalezení odswapované na disku ? (že je celkem normální, aby i desktopový SW šifroval je předpokládám bez diskuse).
echo -n "u48" | sha1sum | head -c3; echo
18.9.2009 14:11 podlesh | skóre: 38 | Praha
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
Ovšem ta feature je určena k něčemu jinému a použít ji pro bezpečné ukládání hesel je jen hack.
Jardík avatar 16.9.2009 00:50 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
základní aplikace pamětí příliš nešetří
Tohle by mohlo být přítomností GC v objective-c, v němž je psána většina GUI programů.
Věřím v jednoho Boha.
16.9.2009 09:10 alblaho
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

ObjC IMHO nemá pořádný GC, pokud vím, tak je v knihovně jenom zabudovaný reference counting. (A dost by mě zajímalo, jak se to chová na víceprocesorovém systému.)

No a taky si matně vybavuju, že Apple inicioval nějakou novou verzi ObjC, možná, že tam je to jinak.

Milan Lajtoš avatar 16.9.2009 00:52 Milan Lajtoš | skóre: 22 | blog: /blog/babraq
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
Skvelé čítanie!

Mám dve otázky. Líši sa nejako nejako správa pamäte v Mac OS X a v Darwine? Porovnať kód je nemožné, takže asi len čo sa týka testov a správania. A ešte druhá - existuje v Darwine/OS X niečo ako OOM-killer na Linuxe?
“Every great achievement was once considered impossible.”
Jardík avatar 16.9.2009 12:46 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
Já myslel, že darwin je jádro MacOS??
Věřím v jednoho Boha.
16.9.2009 12:58 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

 Ono je to takove trosku komplikovane, Darvin je operacni system postaveny nad hybridnim jadrem, kteremu se prezdiva XNU, ktere je slozene z Mach, na ktery jsou nalepene kusy BSD ak tomu je jeste priplacnuty I/O Kit. 

Milan Lajtoš avatar 16.9.2009 14:14 Milan Lajtoš | skóre: 22 | blog: /blog/babraq
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
Jadro nie, skôr základ.

No, ale k veci - Darwin je základ pre Mac OS X, ale neverím, že by si Apple v ňom neporobilo zmeny. Veď to by bolo ako distribuovať vanilla linux. ;)
“Every great achievement was once considered impossible.”
18.9.2009 15:26 eoj
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
Ach jo...
16.9.2009 13:04 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

Teoreticky by se to lisit nemelo ale osobni zkusenosti s darvinem nemam. Zminku o ekvivalentu OOM killera jsem nenasel. Vzhledem k tomu, ze se implicitne swapuje do souboru, ktere se dynamicky vytvareji za behu na korenove partition tak by pri zaplneni disku mohlo dojit k zajimavym jevum. Urcite vyzkousim :-)

 

default avatar 16.9.2009 16:32 default | skóre: 22 | Madrid
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

To ti řeknu docela přesně, co se stane, když dojde místo na disku pro swap. Běží to zoufale pomalu, nejde nic spustit a aplikace buď na akce nereaguje, nebo jde do beach-ballu. :-D Žádnej crash se nekoná. :-D Je na uživateli, aby paměť uvolnil. Ale stalo se mi to jen na Tigeru. Jak reagují Leopard se Snow Leopardem — to netuším.

16.9.2009 21:51 Tomáš Srnka | skóre: 7 | Bratislava/Praha
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
vyskusam, dam vediet ;-) zatial mam 10.5.X, buduci tyzden pojdem na 10.6
17.9.2009 12:27 ..
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
je to tak aj u Leoparda, u Snow Leoparda sa mi to este nepodarilo :)
16.9.2009 09:30 9002
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

Tesim sa na kombinaciu Étoilé a PureDarwin. Niečo ako OpenMacOS :-)

skywaker avatar 16.9.2009 13:10 skywaker | skóre: 24 | blog: Lukove | Prešov
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

ahoj. ja tiež sa tesim na nieco take ale otazka je pouzitelnost takeho niecoho.. maju vobec vyvojary PureDarwina snahu o integraciu etoile? pise sa to niekde? inac zatial je moj favorit Linux a po nom Haiku.

 

Donate Bitcoins to Luko: 14mXEWw9tgTtRT35RSvLL27XSpyety8x3N
rADOn avatar 16.9.2009 11:05 rADOn | skóre: 43 | blog: bloK | Praha
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
Pokud sečtu RSS procesů kernel_task, mds, WindowServer, coreServicesd,... tedy takových, které jen zajišťují chod systému a grafického prostředí, na svém počítači tak se dostanu k úctyhodné hodnotě 1,7 GiB.
Pokud RSS je totez jako v linuxu tak je cislo na houby. Pokud ne, porad je cislo na houby.

Napoveda: pamet mapovana z hw. Pust si v X nejakou hezkou hru a vmsize xserveru vyskoci o stovky mega. Dokonce se mi kdysi kasal jeden kamarad jak je UT2004 skvele napsany ze bere jen 36M fyzicky :-) Bodejt by taky ne, kdyz vsechny textury sly na ucet Xserveru… Bezne se to samozrejme nepozna, ale hry a systemovy procesy nejsou tak uplne bezny.
"2^24 comments ought to be enough for anyone" -- CmdrTaco
16.9.2009 13:36 miho | skóre: 21 | blog: Mihovy_sochory | Orlová
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

 O RSS a obecne o problematice obsazeni pameti procesem jsem psal zde: http://www.abclinuxu.cz/blog/Mihovy_sochory/2007/9/jak-vam-kyne-linux takze sebestredne a nafoukane predpokladam, ze to kazdy zna a vi, co si pod tim ma predstavit! ;-)

 

stativ avatar 16.9.2009 11:29 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
A co je nejhorší, že dochází k nechutné fragmentaci paměti.
Ať sežeru elfa i s chlupama!!! stativ.kx.cz
16.9.2009 15:57 M. Lox | skóre: 12
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
To jo, TLSF ruluje.
make menuconfig, not war!
Snilard avatar 21.9.2009 19:14 Snilard | skóre: 3 | blog: Zápisky Ještěrky | Praha
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

 Jelikož se moc ve správě paměti a alokování v céčku nevyznám, ptám se. Co to pro mne jako uživatele, java, python a snad cocoa programátora znamená?

Znamená to, že si z naprosto zaplněné paměti nemám nic dělat a dokud to nezačne divoce swapovat, není důvod kupovat víc paměti? Můžu nějak systému s pamětí pomoci?

Jsem velký zlý itčko. Jestli budeš zlobit, dostaneš přednášku o Hilbertových prostorech.
stativ avatar 21.9.2009 19:43 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X
To, že se v OS X můžeš setkat s prapodivnými chybami (zejména nepodařené větší alokace) které jinde neuvidíš ;-)
Ať sežeru elfa i s chlupama!!! stativ.kx.cz
Algi avatar 22.9.2009 08:47 Algi | skóre: 1 | blog: Sinner
Rozbalit Rozbalit vše Re: Správa paměti v Mac OS X

 Nikdy jsem si nevšiml, že by se logovalo něco o prapodivných chybách v alokaci. Naopak si všímám v logu prasáren, které někteří programátoři dělají když neumí používat NSAutoreleasePool či leakujou paměť. O tom, že existuje Leaks a Instruments asi nevědí...

Jinak jako programátora v Javě ani v Cocoa tě při dodržování správných zásad nemusí nic trápit. Nevím, jak je tomu u "velkých" aplikací, co potřebují hodně paměti. Do zdrojáků Lightroomu nevidím a zbytek je nenáročný, takže pohoda. Ale třebas jsem jenom naivka, co nevidí pod kapotu ;-)

I'm a firestarter, twisted firestarter...

Založit nové vláknoNahoru

ISSN 1214-1267   Powered by Hosting 90 Server hosting
© 1999-2013 Argonit s. r. o. Všechna práva vyhrazena.