[gnome-devel-docs] Add Czech translation for optimization-guide by Marek Cernocky

[Petr Kovář <pmkovar src gnome org>]

commit 8a61ede1823050bc5e742bc3c8346ef832185972
Author: Petr Kovar <pknbe volny cz>
Date:   Sat Apr 17 21:41:13 2010 +0200

    Add Czech translation for optimization-guide by Marek Cernocky

 optimization-guide/Makefile.am                  |    2 +-
 optimization-guide/cs/cs.po                     |  591 +++++++++++++++++++++++
 optimization-guide/cs/figures/massif-after.png  |  Bin 0 -> 17190 bytes
 optimization-guide/cs/figures/massif-before.png |  Bin 0 -> 16039 bytes
 4 files changed, 592 insertions(+), 1 deletions(-)
---
diff --git a/optimization-guide/Makefile.am b/optimization-guide/Makefile.am
index 5bddacd..680039c 100644
--- a/optimization-guide/Makefile.am
+++ b/optimization-guide/Makefile.am
@@ -2,7 +2,7 @@ include $(top_srcdir)/gnome-doc-utils.make
 dist-hook: doc-dist-hook
 
 DOC_MODULE = optimization-guide
-DOC_LINGUAS = de el es
+DOC_LINGUAS = cs de el es
 DOC_ENTITIES =
 DOC_INCLUDES = \
   optimization-harmful.xml \
diff --git a/optimization-guide/cs/cs.po b/optimization-guide/cs/cs.po
new file mode 100644
index 0000000..cf1c9d3
--- /dev/null
+++ b/optimization-guide/cs/cs.po
@@ -0,0 +1,591 @@
+# Czech translation for gnome-devel-docs.
+# Copyright (C) 2010 gnome-devel-docs's COPYRIGHT HOLDER
+# This file is distributed under the same license as the gnome-devel-docs package.
+# Marek Ä?ernocký <marek manet cz>, 2010.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: gnome-devel-docs master\n"
+"POT-Creation-Date: 2010-04-01 10:39+0000\n"
+"PO-Revision-Date: 2010-04-06 08:32+0100\n"
+"Last-Translator: Marek Ä?ernocký <marek manet cz>\n"
+"Language-Team: Czech <gnome-cs-list gnome org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2;\n"
+
+#: C/optimization-intro.xml:3(title)
+msgid "The Quick Guide to Optimizing GNOME Programs"
+msgstr "Rychlá pÅ?íruÄ?ka k optimalizaci programů GNOME"
+
+#: C/optimization-intro.xml:5(para)
+msgid "This is a brief introduction to optimization, both the hows and the whys. Details of individual tools and techniques are left for later articles, but a collection of hints and tricks is provided."
+msgstr "Toto je struÄ?ný úvod do optimalizace vysvÄ?tlující jak i proÄ?. Podrobnosti k jednotlivým nástrojům a technikám jsou ponechány na jiné Ä?lánky, je ale poskytnuta sbírka rad a triků."
+
+#: C/optimization-intro.xml:10(title)
+msgid "What are we Optimizing?"
+msgstr "Co optimalizujeme?"
+
+#: C/optimization-intro.xml:11(para)
+msgid "When we optimize for GNOME the first thing to remember is this: we are not trying to make the program better, we are trying to make the person using the computer happier."
+msgstr "Když se pouÅ¡tíme do optimalizace pro GNOME, musíme mít na pamÄ?ti zaprvé toto: Nezkoušíme udÄ?lat lepším program, nýbrž zkoušíme udÄ?lat Å¡Å¥astnÄ?jším Ä?lovÄ?ka používajícího poÄ?ítaÄ?."
+
+#: C/optimization-intro.xml:14(para)
+msgid "Better programs make people happier, but there are some improvements that will make them a lot happier than others: Responsiveness, start-up time, easy to access commands and not having the computer go into swap the moment more than two programs are open."
+msgstr "Lepší program dÄ?lá lidi Å¡Å¥astnÄ?jšími, ale nÄ?která vylepÅ¡ení to ovlivní více, než jiná: Odezva, rychlost spouÅ¡tÄ?ní, snadný pÅ?ístup k pÅ?íkazům a to, že nebude poÄ?ítaÄ? odkládat data na disk ve chvíli, kdy spustíte více než dva programy."
+
+#: C/optimization-intro.xml:17(para)
+msgid "Traditional optimization tackles concepts like CPU use, code size, the number of mouse clicks and the memory use of the program. This second list has been chosen to correlate with the first list, however there is an important difference: The person using GNOME doesn't care about the second list, but they care a lot about the first list. When optimizing GNOME programs we will reduce CPU use, memory use and all those things, but these are the means to the end, not the final goal. We are optimizing for people."
+msgstr "TradiÄ?ní optimalizace Å?eší takové vÄ?ci, jako je využití procesoru, velikost kódu, poÄ?et kliknutí myší a využití pamÄ?ti programem. Tento druhý seznam byl zvolen tak, aby mÄ?l pÅ?ímou souvislost s prvnÄ? uvedeným, je zde ale nÄ?kolik podstatných rozdílů: Osoba používající GNOME se nestará o druhý seznam, ale zajímá ji ten první. PÅ?i optimalizaci programů GNOME budeme snižovat zátÄ?ž procesoru, využití pamÄ?ti a vÅ¡echny tyto vÄ?ci, ale je to jen cesta k Å?eÅ¡ení, ne cíl. Optimalizujeme pro lidi."
+
+#: C/optimization-intro.xml:23(title)
+msgid "Doing the Optimization"
+msgstr "Optimalizujeme"
+
+#: C/optimization-intro.xml:24(para)
+msgid "The previous section omitted one important qualifier: To optimize something it has to be measurable. You can't measure happiness. However, you can measure start-up time so you can tell if you have improved it. Happiness will then, hopefully, follow."
+msgstr "PÅ?edchozí oddíl opominul jeden důležitý kvalifikátor: Optimalizovat se dá jen to, co je mÄ?Å?itelné. Nemůžete mÄ?Å?it Å¡tÄ?stí. Můžete ale zmÄ?Å?it dobu spouÅ¡tÄ?ní a zjistit tak, zda jste ji zkrátili. Å tÄ?stí pak bude, snad, následovat."
+
+#: C/optimization-intro.xml:27(para)
+msgid "Optimization is the process of measurement, refinement and re-measurement. So the first thing you must do is find a way to measure what you are optimizing. Ideally this measurement is a single number, for example: the time taken to perform a task. This is your benchmark, it is the only way to tell if you are winning or losing. There is a big difference between a program that <emphasis>should</emphasis> be fast and a program that <emphasis>is</emphasis> fast."
+msgstr "Optimalizace je proces mÄ?Å?ení, vypilovávání a opÄ?tovného mÄ?Å?ení. To znamená, že první vÄ?c, co musíte udÄ?lat, je najít způsob, jak zmÄ?Å?it to, co chcete optimalizovat. V ideálním pÅ?ípadÄ? je výsledkem mÄ?Å?ení jedno Ä?íslo, napÅ?íklad Ä?as potÅ?ebný k provedení úlohy. Je to váš test výkonu a jde jen o způsob, jak se dovÄ?dÄ?t, zda jste zvítÄ?zili nebo ne. Je velký rozdíl mezi programem, který by <emphasis>mÄ?l</emphasis> být rychlý a programem, který <emphasis>je</emphasis> rychlý."
+
+#: C/optimization-intro.xml:30(para)
+msgid "Once you have a basic benchmark you need to find out why your code is not doing as well as it should. It is tempting to do this by inspection: just looking at the code and trying to spot something that looks like it needs improvement. You will invariably be wrong. Using a profiler to get a detailed break-down of what your program really does is the only way to be sure."
+msgstr "Když máte základní test výkonu, potÅ?ebujete najít proÄ? váš kód nedÄ?lá vÄ?ci tak dobÅ?e, jak by mÄ?l. Svádí to ke zkoumání: podívat se na kód a zkusit vystopovat nÄ?co, co vypadá, že by potÅ?ebovalo vylepÅ¡it. Zpravidla budete neúspÄ?Å¡ní. Jediný způsob, jak s jistotou podrobnÄ? zjistit co se v programu kazí, je použít profiler."
+
+#: C/optimization-intro.xml:33(para)
+msgid "Usually the problem is isolated to small sections of code. Pick the worst place and concentrate on that first. Once that is done, rerun the profiler and repeat. As you proceed the gains made at each step will get less and less, at some point you will have to decide that the results are good enough. If your efforts are only extracting 10% improvements then you are well past the point where you should have stopped."
+msgstr "Obvykle je problém izolovat malý oddíl kódu. VypíchnÄ?te nejhorší místo a nejprve se soustÅ?eÄ?te na nÄ?j. Když to udÄ?láte, spusÅ¥te znovu profiler a opakujte to. PostupnÄ? vytÄ?žíte z každého kroku ménÄ? a ménÄ?, až do chvíle, kdy se rozhodnete, že je výsledek dostateÄ?nÄ? dobrý. Pokud pÅ?es úsilí získáte jen 10% zlepÅ¡ení, je mÄ?ly byste se pÅ?estat zabývat tímto místem."
+
+#: C/optimization-intro.xml:36(para)
+msgid "Don't forget the big picture. For example, rather than just trying to speed up a piece of code, ask yourself if it needs to be run at all. Could it be combined with another piece of code? Can the results of previous calculations be saved and reused? It won't even need to be optimized if it is in a place where the user is never going to notice it. Worse still, the code may already be optimized and is doing the heavy calculations now to avoid doing them later. Code does not run in isolation and neither does the optimization process."
+msgstr "NezapomeÅ?te se na to dívat jako na celek. Než napÅ?íklad zkouÅ¡et zrychlit kousek kódu, zeptejte se sami sebe, jestli jej vůbec potÅ?ebujete spouÅ¡tÄ?t. Mohl by být slouÄ?en s jiným kusem kódu? Je možné výsledky pÅ?edchozích výpoÄ?tů uložit a znovu použít? Optimalizace není potÅ?eba, pokud jde o místo, kterého si uživatel nikdy nevÅ¡imne. Pokud je to stále horší, možná byl kód již optimalizován a provádí nároÄ?né výpoÄ?ty, aby se nemusely dÄ?lat pozdÄ?ji. Nebo kód nebÄ?ží izolovanÄ? a nebo vůbec optimalizovat nepůjde."
+
+#: C/optimization-intro.xml:41(title)
+msgid "Hints"
+msgstr "Rady"
+
+#: C/optimization-intro.xml:43(title)
+msgid "The Fundamentals"
+msgstr "Základní"
+
+#: C/optimization-intro.xml:45(para)
+msgid "Re-run your benchmark after every change you make to the code and keep a log of everything you change and how it affects the benchmark. This lets you undo mistakes and also helps you not to repeat mistakes."
+msgstr "SpusÅ¥te testování výkonu po každé zmÄ?nÄ?, kterou udÄ?láte v kódu, a udržujte si evidenci vÅ¡ech svých zmÄ?n a toho, jak test výkonu ovlivnily. To vám umožní napravit chyby a vyvarovat se stejných chyb do budoucna."
+
+#: C/optimization-intro.xml:50(para)
+msgid "Make sure your code is correct and bug-free before optimizing it. Check that it remains correct and bug-free after optimization."
+msgstr "PÅ?ed zapoÄ?etím optimalizace se ujistÄ?te, že je váš kód správný a bez chyb. Tím se vyvarujete oprav a ladÄ?ní chyb po optimalizaci."
+
+#: C/optimization-intro.xml:55(para)
+msgid "Optimize at the high level before optimizing the details."
+msgstr "Než zaÄ?nete optimalizovat detaily, zamÄ?Å?te se na optimalizaci na vyšší úrovni."
+
+#: C/optimization-intro.xml:60(para)
+msgid "Use the right algorithm. The classic text-book example is using quick-sort instead of bubble-sort. There are many others, some save memory, some save CPU. Also, see what shortcuts you can make: you can do quicker than quick-sort if you are prepared to make some compromises."
+msgstr "Používejte správné algoritmy. Klasickým pÅ?íkladem uvádÄ?ným v knihách je nasazení quick-sort namísto bubble-sort. Takových pÅ?íkladů existuje celá Å?ada, nÄ?které Å¡etÅ?í pamÄ?Å¥, jiné výkon procesoru. Také se podívejte, co můžete udÄ?lat jednoduÅ¡eji: můžete použít i rychlejší algoritmus než je quick-sort, pokud se pÅ?ipravíte udÄ?lat urÄ?ité kompromisy."
+
+#: C/optimization-intro.xml:65(para)
+msgid "Optimization is a trade-off. Caching results speeds up calculations, but increases memory use. Saving data to disk saves memory, but costs time when it is loaded back from disk."
+msgstr "Optimalizace je o kompromisech. Ukládání výsledků do mezipamÄ?ti zrychlí výpoÄ?ty, ale zároveÅ? zvýší použití pamÄ?ti. Ukládání dat na disk uÅ¡etÅ?í pamÄ?Å¥, ale platíme za to Ä?asem potÅ?ebným k jejich naÄ?tení z disku nazpÄ?t."
+
+#: C/optimization-intro.xml:70(para)
+msgid "Make sure you choose a wide variety of inputs to optimize against. If you don't it is easy to end up with a piece of code carefully optimized for one file and no others."
+msgstr "UjistÄ?te se, že jste provedli optimalizaci vůÄ?i Å¡iroké paletÄ? vstupních dat. Pokud tak neuÄ?iníte, můžete skonÄ?it s kusem kódu peÄ?livÄ? optimalizovaným pro jedno pole, ale ne tak pro ostatní."
+
+#: C/optimization-intro.xml:75(para)
+msgid "Avoid expensive operations: Multiple small disk reads. Using up lots of memory so disk swapping becomes necessary. Avoid anything that writes or reads from the hard disk unnecessarily. The network is slow too. Also avoid graphics operations that need a response from the X server."
+msgstr "Vyvarujte se nároÄ?ných operací: Spousty malých Ä?tení z disku. Používání velkého množství pamÄ?ti, které způsobuje odkládání na disk. Vyvarujte se jakýchkoliv ne nutnÄ? nezbytných diskových operací, Ä?tení i zápisu. Síť může být také pomalá. RovnÄ?ž omezte grafické operace, které potÅ?ebují odezvu od X serveru."
+
+#: C/optimization-intro.xml:81(title)
+msgid "Traps for the Unwary"
+msgstr "Nástrahy a léÄ?ky"
+
+#: C/optimization-intro.xml:83(para)
+msgid "Beware of side effects. There can often be strange interactions between different sections of code, a speed-up in one part can slow another part down."
+msgstr "Dejte si pozor na vedlejší efekty. Ä?astá je vzájemná vazba mezi různými Ä?ástmi kódu, takže zrychlení jedné Ä?ásti může způsobit zpomalení jiné."
+
+#: C/optimization-intro.xml:88(para)
+msgid "When timing code, even on a quiet system, events outside the program add noise to the timing results. Average over multiple runs. If the code is very short, timer resolution is also a problem. In this case measure the time the computer takes to run the code 100 or 1000 times. If the times you are recording are longer than a few seconds, you should be OK."
+msgstr "Když mÄ?Å?íte Ä?as kódu, i na systému v klidu ovlivÅ?ují Ä?as události mimo program. Používejte průmÄ?rnou hodnotu z více spuÅ¡tÄ?ní. Pokud je kód velmi krátký, může být mÄ?Å?ení Ä?asu také problematické. V takovém pÅ?ípadÄ? mÄ?Å?te Ä?as pro 100 nebo 1000 opakovaných spuÅ¡tÄ?ní kódu. Když je zaznamenaný Ä?as delší než nÄ?kolik sekund, mÄ?lo by to být v poÅ?ádku."
+
+#: C/optimization-intro.xml:93(para)
+msgid "It is very easy to be misled by the profiler. There are stories of people optimizing the operating system idle-loop because that is where it spent all its time! Don't optimize code that does nothing the user cares about."
+msgstr "Je velmi snadné nechat se zmást profilerem. Existují historky o lidech, kteÅ?í optimalizovali Ä?ekací smyÄ?ku operaÄ?ního systému, protože tam program trávil vÄ?tÅ¡inu Ä?asu. Neoptimalizujte kód, který nedÄ?lá nÄ?co, co by zajímalo uživatele."
+
+#: C/optimization-intro.xml:98(para)
+msgid "Remember the resources on the X server. Your program's memory usage doesn't include the pixmaps that are stored in the X server's process, but they are still using up memory. Use xrestop to see what resources your program is using."
+msgstr "Pamatujte na zdroje X serveru. Využití pamÄ?ti vaším programem nezahrnuje pixelové mapy, protože ty jsou uložené v procesu X serveru, ale pamÄ?Å¥ tak jako tak okupují. Pomocí xrestop se můžete podívat, které zdroje váš program používá."
+
+#: C/optimization-intro.xml:104(title)
+msgid "Low Level Hints"
+msgstr "Rady pro nízkoúrovÅ?ové programování"
+
+#: C/optimization-intro.xml:106(para)
+msgid "When optimizing memory use, be wary of the difference between peak usage and average memory usage. Some memory is almost always allocated, this is usually bad. Some is only briefly allocated, this may be quite acceptable. Tools like massif use the concept of space-time, the product of memory used and the duration it was allocated for, instead."
+msgstr "Když optimalizujete využití pamÄ?ti, berte na vÄ?domí rozdíl mezi Å¡piÄ?kovým využitím a průmÄ?rným využitím. NÄ?jaká pamÄ?Å¥ je skoro vždy alokovaná, což je obvykle Å¡patnÄ?. NÄ?jaká je alokovaná jen zÅ?ídka, což může být pÅ?ijatelné. Nástroje, jako je massif, místo toho používají koncept Ä?asoprostoru (spacetime), kdy sledují kolik pamÄ?ti je využito i na jak dlouho je alokována."
+
+#: C/optimization-intro.xml:111(para)
+msgid "Time simplified bits of code that do only the things you know are essential, this gives an absolute lower limit on the time your code will take. For example, when optimizing a loop time the empty loop. If that is still too long no amount of micro-optimization will help and you will have to change your design. Make sure the compiler doesn't optimize away your empty loop."
+msgstr "ZmÄ?Å?te Ä?as zjednoduÅ¡eného kousku kódu, který dÄ?lá jen to, co považujete za podstatné, Ä?ímž získáte nejnižší Ä?asový limit, kterého může kód dosáhnout. NapÅ?íklad, když optimalizujete smyÄ?ku, zmÄ?Å?te Ä?as prázdné smyÄ?ky. Pokud i to zabere pÅ?íliÅ¡ mnoho Ä?asu, jakékoliv mikrooptimalizace vám nepomohou a je potÅ?eba zásadnÄ? zmÄ?nit návrh. UjistÄ?te se, že pÅ?ekladaÄ? v rámci optimalizace smyÄ?ku nevyhodí."
+
+#: C/optimization-intro.xml:116(para)
+msgid "Move code out from inside loops. A slightly more complicated piece of code that is executed once is far quicker than a simple piece of code executed a thousand times. Avoid calling slow code often."
+msgstr "PÅ?esuÅ?te kód mimo programové smyÄ?ky. Trochu složitÄ?jší Ä?ást kódu, která se spustí jednou je mnohem rychlejší, než jednodušší Ä?ást, která se spouÅ¡tí tisíckrát. Vyvarujte se Ä?astému volání pomalého kódu."
+
+#: C/optimization-intro.xml:121(para)
+msgid "Give the compiler as many hints as possible. Use the const keyword. Use <envar>G_INLINE_FUNC</envar> for short, frequently called, functions. Look up <envar>G_GNUC_PURE</envar>, <envar>G_LIKELY</envar> and the other glib miscellaneous macros. Use the macros instead of gcc-specific keywords to ensure portability."
+msgstr "PoskytnÄ?te pÅ?ekladaÄ?i co nejvíce rad je možné. Používejte klíÄ?ové slovo const. Používejte <envar>G_INLINE_FUNC</envar> pro krátké, Ä?asto volané funkce. Podívejte se na <envar>G_GNUC_PURE</envar>, <envar>G_LIKELY</envar> a další různá makra glib. Používejte makra namísto klíÄ?ových slov specifických pro pÅ?ekladaÄ? gcc, abyste zajistili pÅ?enositelnost."
+
+#: C/optimization-intro.xml:126(para)
+msgid "Don't use assembly language. It is not portable and, while it may be fast on one processor, it is not even guaranteed to be fast on every processor that supports that architecture (e.g. Athlon vs. Pentium 4)."
+msgstr "Nepoužívejte jazyk assembler. Není pÅ?enositelný a aÄ?koliv může být na jednom procesoru rychlý, nikde není garantováno, že bude rychlý na vÅ¡ech procesorech, které podporují danou architekturu (napÅ?. Athlon vs. Pentium 4)."
+
+#: C/optimization-intro.xml:131(para)
+msgid "Don't rewrite an existing library routine unless you are sure it is unnecessarily slow. Many CPU-intensive library routines have already been optimized. Conversely, some library routines are slow, especially ones that make system calls to the operating system."
+msgstr "NepÅ?episujte stávající knihovní rutiny, pokud si nejste opravdu jistí, že jsou pÅ?ehnanÄ? pomalé. Å?ada knihovních rutin, které intenzivnÄ? využívají procesor, již byla optimalizována. Naopak, nÄ?které knihovní rutiny jsou pomalé, zvláštÄ? ty, které provádí systémová volání operaÄ?ního systému."
+
+#: C/optimization-intro.xml:136(para)
+msgid "Minimize the number of libraries you link to. The fewer libraries to link in, the faster the program starts. This is a difficult thing to do with GNOME."
+msgstr "Minimalizujte poÄ?et vazeb na knihovny. Na Ä?ím ménÄ? knihoven se bude program vázat, tím rychleji bude startovat. Toto je vÄ?c, která se v GNOME dÄ?lá obtížnÄ?."
+
+#: C/optimization-intro.xml:142(title)
+msgid "High Level Tricks"
+msgstr "Triky pro vysokoúrovÅ?ové programování"
+
+#: C/optimization-intro.xml:144(para)
+msgid "Take advantage of concurrency. This doesn't just mean using multiple processors, it also means taking advantage of the time the user spends thinking about what they are going to do next to perform some calculations in anticipation. Do calculations while waiting for data to be loaded off disk. Take advantage of multiple resources, use them all at once."
+msgstr "Užívejte výhod bÄ?hu více vÄ?cí. To nemusí nutnÄ? znamenat použití více procesorů, může to znamenat i využití Ä?asu, který uživatel tráví pÅ?emýšlením, co hodná dále dÄ?lat, k provádÄ?ní výpoÄ?tů pÅ?edem. ProvádÄ?jte výpoÄ?ty bÄ?hem Ä?ekání na naÄ?tení dat z disku. Využívejte výhod více zdrojů, používejte je vÅ¡echny naráz."
+
+#: C/optimization-intro.xml:149(para)
+msgid "Cheat. The user only has to think that the computer is fast, it doesn't matter whether it actually is or not. It is the time between the command and the answer that is important, it doesn't matter if the response is pre-calculated, cached, or will in fact be worked out later at a more convenient time, as long as the user gets what they expect."
+msgstr "Å vindlujte. Uživatel si pouze musí myslet, že je poÄ?ítaÄ? rychlejší, není podstatné, jestli tomu tak skuteÄ?nÄ? je. Jde o to, že důležitý je Ä?as mezi pÅ?íkazem a odpovÄ?dí a pokud uživatel dostane co oÄ?ekává, není podstatné jestli je odpovÄ?Ä? vypoÄ?ítaná dopÅ?edu, uložená v mezipamÄ?ti nebo bude ve skuteÄ?nosti zpracována pozdÄ?ji v pÅ?íhodnÄ?jším Ä?ase."
+
+#: C/optimization-intro.xml:154(para)
+msgid "Do things in the idle loop. It is easier to program than using full multi-threading but still gets things done out of the users eye. Be careful though, if you spend too long in the idle loop your program will become sluggish. So regularly give control back to the main loop."
+msgstr "ProvádÄ?jte vÄ?ci v Ä?ekací smyÄ?ce. Je to jednodušší, než program, který používá plnÄ? vícevláknový bÄ?h, a pÅ?esto můžete provádÄ?t vÄ?ci skrytÄ? pÅ?ed zraky uživatelů. Ale pozor, pokud strávíte pÅ?íliÅ¡ Ä?asu v Ä?ekací smyÄ?ce, bude program reagovat rychlostí Å¡neka. NezapomeÅ?te pravidelnÄ? pÅ?edávat Å?ízení zpÄ?t do hlavní smyÄ?ky."
+
+#: C/optimization-intro.xml:159(para)
+msgid "If all else fails, tell the user that the code is going to be slow and put up a progress bar. They won't be as happy as if you had just presented the results, but they will at least know the program hasn't crashed and they can go get a cup of coffee."
+msgstr "Když vÅ¡e ostatní selže, alespoÅ? oznamte uživateli, že provádÄ?ní bude pomalé a zobrazte ukazatel průbÄ?hu. Sice nebude tak Å¡Å¥astný, jako kdybyste mu zobrazili výsledky, ale aspoÅ? bude vÄ?dÄ?t, že program nezkolaboval a že si může zatím dát káviÄ?ku."
+
+#. When image changes, this message will be marked fuzzy or untranslated for you.
+#. It doesn't matter what you translate it to: it's not used at all.
+#: C/optimization-massif.xml:52(None)
+msgid "@@image: 'figures/massif-before.png'; md5=1a6b2ace548e6789ab8bfacb3727b345"
+msgstr "@@image: 'figures/massif-before.png'; md5=1a6b2ace548e6789ab8bfacb3727b345"
+
+#. When image changes, this message will be marked fuzzy or untranslated for you.
+#. It doesn't matter what you translate it to: it's not used at all.
+#: C/optimization-massif.xml:114(None)
+msgid "@@image: 'figures/massif-after.png'; md5=36d1b4ad7ab49b28b69ad3eabbaa7069"
+msgstr "@@image: 'figures/massif-after.png'; md5=36d1b4ad7ab49b28b69ad3eabbaa7069"
+
+#: C/optimization-massif.xml:3(title)
+msgid "Using <application>Massif</application> for Profiling Memory Use in GNOME Software"
+msgstr "Použití aplikace <application>Massif</application> k profilování využití pamÄ?ti v softwaru GNOME"
+
+#: C/optimization-massif.xml:5(para)
+msgid "This article describes how to use the <application>Massif</application> heap profiler with GNOME applications. We describe how to invoke, interpret, and act on the output of <application>Massif</application>. The <application>Same GNOME</application> game is used as an example."
+msgstr "Tento Ä?lánek popisuje profiler zásobníku <application>Massif</application> s aplikacemi GNOME. Popisuje jak získat, interpretovat a využít výstup z aplikace <application>Massif</application>. Jako pÅ?íklad je použita hra <application>Stejný GNOME</application>."
+
+#: C/optimization-massif.xml:10(title)
+msgid "Introduction"
+msgstr "Ã?vod"
+
+#: C/optimization-massif.xml:11(para)
+msgid "<application>Massif</application> is a member of the <ulink type=\"http\" url=\"http://valgrind.org/\";>valgrind</ulink> suite of memory-profiling tools. Its purpose is to give a detailed view of dynamic memory usage during the lifetime of the program. Specifically it records the memory use of the heap and the stack."
+msgstr "<application>Massif</application> je souÄ?ástí sady nástrojů na profilování pamÄ?ti <ulink type=\"http\" url=\"http://valgrind.org/\";>valgrind</ulink>. Jeho úÄ?elem je poskytnout podrobný pohled na dynamické využití pamÄ?ti bÄ?hem životního cyklu programu. SpeciálnÄ? zaznamenává využití pamÄ?ti haldy a zásobníku."
+
+#: C/optimization-massif.xml:14(para)
+msgid "The heap is the region of memory which is allocated with functions like malloc. It grows on demand and is usually the largest region of memory in a program. The stack is where all the local data for functions is stored. This includes the \"automatic\" variables in C and the return address for subroutines. The stack is typically a lot smaller and a lot more active than the heap. We won't consider the stack explicitly since <application>Massif</application> treats it as though it were just another part of the heap. <application>Massif</application> also gives information about how much memory is used to manage the heap."
+msgstr "Halda je oblast pamÄ?ti, která se alokuje funkcemi jako je malloc. Podle požadavků se zvÄ?tÅ¡uje a obvykle je to nejvÄ?tší pamÄ?Å¥ová oblast v programu. Zásobník je místo, ve kterém jsou uchovávána lokální data funkcí. To zahrnuje â??automatickéâ?? promÄ?nné v C a návratovou adresu podprogramu. Zásobník je obvykle podstatnÄ? menší a ménÄ? aktivní než halda. Zásobníkem se výslovnÄ? zabývat nechceme, protože aplikace <application>Massif</application> s ním zachází stejnÄ?, jako by to byla jen další Ä?ást haldy. Aplikace <application>Massif</application> rovnÄ?ž poskytuje informace o tom, kolik pamÄ?ti je využito ke správÄ? haldy."
+
+#: C/optimization-massif.xml:17(para)
+msgid "<application>Massif</application> produces two output files: a graphical overview in a postscript file and a detailed breakdown in a text file."
+msgstr "Aplikace <application>Massif</application> vytváÅ?í dva výstupní soubory: grafický pÅ?ehled v postskriptovém souboru a podrobný rozpis v textovém souboru."
+
+#: C/optimization-massif.xml:22(title)
+msgid "Using <application>Massif</application> with GNOME"
+msgstr "Používání aplikace <application>Massif</application> s GNOME"
+
+#: C/optimization-massif.xml:23(para)
+msgid "<application>Massif</application> has very few options and for many programs does not need them. However for GNOME applications, where memory allocation might be buried deep in either glib or GTK, the number of levels down the call-stack Massif descends needs to be increased. This is achieved using the --depth parameter. By default this is 3; increasing it to 5 will guarantee the call-stack reaches down to your code. One or two more levels may also be desirable to provide your code with some context. Since the level of detail becomes quickly overwhelming it is best to start with the smaller depth parameter and only increase it when it becomes apparent that it isn't sufficient."
+msgstr "Aplikace <application>Massif</application> má jen velmi málo pÅ?epínaÄ?ů a pro mnoho programů je ani nepotÅ?ebujete. Když ale aplikace pro GNOME alokují pamÄ?Å¥, mohou se zanoÅ?it  hluboko do glib nebo GTK, a proto je potÅ?eba zvýšit poÄ?et úrovní zanoÅ?ení zásobníku volání v Massif. Toho se dosáhne použitím pÅ?epínaÄ?e --depth. Výchozí je 3, zvýšení na 5 zajistí dostatek zdrojů zásobníku volání pro váš kód. Jedna nebo více úrovní může být také žádoucí k poskytnutí vaÅ¡eho kódu s nÄ?jakým kontextem. Jelikož s úrovní podrobností pÅ?ichází rychlé zahlcení, je nejlepší zaÄ?ít s menší hodnotou pÅ?epínaÄ?e depth a zvýšit ji jen v pÅ?ípadÄ?, kdy se ukáže nedostaÄ?ující."
+
+#: C/optimization-massif.xml:26(para)
+msgid "It is also useful to tell <application>Massif</application> which functions allocate memory in glib. It removes an unnecessary layer of function calls from the reports and gives you a clearer idea of what code is allocating memory. The allocating functions in glib are g_malloc, g_malloc0, g_realloc, g_try_malloc, and g_mem_chunk_alloc. You use the --alloc-fn option to tell Masiff about them."
+msgstr "UžiteÄ?né je také aplikaci <application>Massif</application> sdÄ?lit, které funkce v glib alokují pamÄ?Å¥. Tím se odstraní z výstupní sestavy vrstvy volání funkcí, které nejsou nutné a získáte tak jasnÄ?jší pÅ?ehled, který kód alokuje pamÄ?Å¥. AlokaÄ?ní funkce glib jsou g_malloc, g_malloc0, g_realloc, g_try_malloc a g_mem_chunk_alloc. Aplikaci Masiff to sdÄ?líte pÅ?epínaÄ?em --alloc-fn."
+
+#: C/optimization-massif.xml:29(para)
+msgid "Your command-line should therefore look something like:"
+msgstr "Váš pÅ?íkazový Å?ádek by pro pÅ?edchozí mÄ?l vypadat nÄ?jak takto:"
+
+#: C/optimization-massif.xml:32(programlisting)
+#, no-wrap
+msgid ""
+"\n"
+"valgrind --tool=massif --depth=5  --alloc-fn=g_malloc --alloc-fn=g_realloc --alloc-fn=g_try_malloc \\\n"
+"         --alloc-fn=g_malloc0 --alloc-fn=g_mem_chunk_alloc same-gnome\n"
+"        "
+msgstr ""
+"\n"
+"valgrind --tool=massif --depth=5  --alloc-fn=g_malloc --alloc-fn=g_realloc --alloc-fn=g_try_malloc \\\n"
+"         --alloc-fn=g_malloc0 --alloc-fn=g_mem_chunk_alloc same-gnome\n"
+"        "
+
+#: C/optimization-massif.xml:36(para)
+msgid "<application>Same GNOME</application> is the program we will be using as an example. Be warned that, since valgrind emulates the CPU, it will run <emphasis>very</emphasis> slowly. You will also need a lot of memory."
+msgstr "<application>Same GNOME / Stejný GNOME</application> je program, který je použit jako ukázkový. DopÅ?edu vás varujeme, že valgrind emuluje procesor, takže bÄ?h je <emphasis>velmi</emphasis> pomalý. K tomu jeÅ¡tÄ? budete potÅ?ebovat velké množství pamÄ?ti."
+
+#: C/optimization-massif.xml:41(title)
+msgid "Interpreting the Results"
+msgstr "Interpretace výsledků"
+
+#: C/optimization-massif.xml:42(para)
+msgid "The graphical output of <application>Massif</application> is largely self explanatory. Each band represents the memory allocated by one function over time. Once you identify which bands are using the most memory, usually the big thick ones at the top you will have to consult the text file for the details."
+msgstr "Grafický výstup aplikace <application>Massif</application> je pochopitelný i bez vysvÄ?tlování. Každý pás pÅ?edstavuje pamÄ?Å¥ alokovanou jednou funkcí v průbÄ?hu Ä?asu. Když zjistíte, který pás využívá nejvíce pamÄ?ti, což je obvykle ten nejtlustší z nich nahoÅ?e, dohledejte si k nÄ?mu podrobnosti v textovém souboru."
+
+#: C/optimization-massif.xml:45(para)
+msgid "The text file is arranged as a hierarchy of sections, at the top is a list of the worst memory users arranged in order of decreasing spacetime. Below this are further sections, each breaking the results down into finer detail as you proceed down the call-stack. To illustrate this we will use the output of the command above."
+msgstr "Textový soubor je uspoÅ?ádán do hierarchie oddílů, na zaÄ?átku je seznam nejhorších uživatelů pamÄ?ti v sestupném poÅ?adí podle Ä?asoprostoru. Nasledují další oddíly, každý rozebírající výsledky do vÄ?tších podrobností, jak se postupnÄ? zanoÅ?ujete do zásobníku volání. Pro ilustraci použijeme výstup pÅ?edchozího pÅ?íkazu."
+
+#: C/optimization-massif.xml:49(title)
+msgid "<application>Massif</application> output for the unoptimized version of the <application>Same GNOME</application> program."
+msgstr "Výstup z aplikace <application>Massif</application> pro neoptimalizovanou verzi prgramu <application>Stejný GNOME</application>."
+
+#: C/optimization-massif.xml:56(para)
+msgid "<xref linkend=\"optimization-massif-FIG-output-unoptimized\"/> shows a typical postscript output from <application>Massif</application>. This is the result you would get from playing a single game of <application>Same GNOME</application> (version 2.8.0) and then quitting. The postscript file will have a name like <filename>massif.12345.ps</filename> and the text file will be called <filename>massif.12345.txt</filename>. The number in the middle is the process ID of the program that was examined. If you actually try this example you will find two versions of each file, with slightly different numbers, this is because <application>Same GNOME</application> starts a second process and <application>Massif</application> follows that too. We will ignore this second process, it consumes very little memory."
+msgstr "<xref linkend=\"optimization-massif-FIG-output-unoptimized\"/> ukazuje typický postskriptový výstup z aplikace <application>Massif</application>. Toto je výsledek, který byste získali, když odehrajete jednu hry <application>Stejný GNOME</application> (verze 2.8.0) a po té ji ukonÄ?íte. Postskriptový soubor bude mít název ve stylu <filename>massif.12345.ps</filename> a textový soubor bude nazván <filename>massif.12345.txt</filename>. Ä?íslo uprostÅ?ed je ID procesu programu, který byl spuÅ¡tÄ?n. Pokud právÄ? zkoušíte tento pÅ?íklad, najdete dvÄ? verze každého souboru s lehce odliÅ¡nými Ä?ísly, což je proto, že aplikace <application>Stejný GNOME</application> spouÅ¡tí druhý proces a aplikace <application>Massif</application> jej následuje. Tento druhý proces budeme ignorovat, spotÅ?ebovává jen velmi málo pamÄ?ti."
+
+#: C/optimization-massif.xml:59(para)
+msgid "At the top of the graph we see a large yellow band labelled gdk_pixbuf_new. This seems like an ideal candidate for optimization, but we will need to use the text file to find out what is calling gdk_pixbuf_new. The top of the text file will look something like this:"
+msgstr "V horní Ä?ásti grafu vidíme velký žlutý pás oznaÄ?ený gdk_pixbuf.new. Ten se zdá jako nejlepší kandidát na optimalizaci, ale nejdÅ?íve potÅ?ebujeme použít textový soubor, abychom naÅ¡li co gdk_pixbuf_new volá. ZaÄ?átek textového souboru vypadá nÄ?jak takto:"
+
+#: C/optimization-massif.xml:62(programlisting)
+#, no-wrap
+msgid ""
+"\n"
+"Command: ./same-gnome \n"
+"\n"
+"== 0 ===========================\n"
+"Heap allocation functions accounted for 90.4% of measured spacetime\n"
+"\n"
+"Called from:\n"
+"  28.8% : 0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
+"\n"
+"    6.1% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)\n"
+"\n"
+"    5.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)\n"
+"\n"
+"    3.5% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)\n"
+"        "
+msgstr ""
+"\n"
+"PÅ?íkaz: ./same-gnome \n"
+"\n"
+"== 0 ===========================\n"
+"Funkce pro alokaci haldy zodpovídají za 90,40% mÄ?Å?eného Ä?asoprostoru\n"
+"\n"
+"Voláno z:\n"
+"  28.8% : 0x6BF83A: gdk_pixbuf_new (v /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
+"\n"
+"    6.1% : 0x5A32A5: g_strdup (v /usr/lib/libglib-2.0.so.0.400.6)\n"
+"\n"
+"    5.9% : 0x510B3C: (uvnitÅ? /usr/lib/libfreetype.so.6.3.7)\n"
+"\n"
+"    3.5% : 0x2A4A6B: __gconv_open (v /lib/tls/libc-2.3.3.so)\n"
+"        "
+
+#: C/optimization-massif.xml:77(para)
+msgid "The line with the '=' signs indicates how far down the stack trace we are, in this case we are at the top. After this it lists the heaviest users of memory in order of decreasing spacetime. Spacetime is the product of the amount of memory used and how long it was used for. It corresponds to the area of the bands in the graph. This part of the file tells us what we already know: most of the spacetime is dedicated to gdk_pixbuf_new. To find out what called gdk_pixbuf_new we need to search further down the text file:"
+msgstr "Å?ádek se znaky â??=â?? uvádí, jak hluboko v zásobníku sledování jsme zanoÅ?ení, v tomto konkrétním pÅ?ípadÄ? jsem úplnÄ? nahoÅ?e. Následuje seznam nejnároÄ?nÄ?jších uživatelů pamÄ?ti v sestupném poÅ?adí podle Ä?asoprostoru. Ä?asoprostor je veliÄ?ina pÅ?edstavující jak moc pamÄ?ti je použito a jako dlouho je použita. Odpovídá to ploÅ¡e pásu v grafu. Tato Ä?ást souboru nám Å?íká, co již víme: nejvíce Ä?asoprostoru si zabrala funkce gdk_pisbuf_new. Abychom vÄ?dÄ?li, co gdk_pixbuf_new volá, musíme hledat v textovém souboru dále:"
+
+#: C/optimization-massif.xml:80(programlisting)
+#, no-wrap
+msgid ""
+"\n"
+"== 4 ===========================\n"
+"Context accounted for 28.8% of measured spacetime\n"
+"  0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
+"  0x3A998998: (within /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so)\n"
+"  0x6C2760: (within /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
+"  0x6C285E: gdk_pixbuf_new_from_file (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
+"\n"
+"Called from:\n"
+"  27.8% : 0x804C1A3: load_scenario (same-gnome.c:463)\n"
+"\n"
+"    0.9% : 0x3E8095E: (within /usr/lib/libgnomeui-2.so.0.792.0)\n"
+"\n"
+"  and 1 other insignificant place\n"
+"        "
+msgstr ""
+"\n"
+"== 4 ===========================\n"
+"Kontext zodpovídá za 28,8% mÄ?Å?eného Ä?asového prostoru\n"
+"  0x6BF83A: gdk_pixbuf_new (v /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
+"  0x3A998998: (uvnitÅ? /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so)\n"
+"  0x6C2760: (uvnitÅ? /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
+"  0x6C285E: gdk_pixbuf_new_from_file (v /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
+"\n"
+"Voláno z:\n"
+"  27.8% : 0x804C1A3: load_scenario (same-gnome.c:463)\n"
+"\n"
+"    0.9% : 0x3E8095E: (uvnitÅ? /usr/lib/libgnomeui-2.so.0.792.0)\n"
+"\n"
+"  a 1 dalšího nedůležitého místa\n"
+"        "
+
+#: C/optimization-massif.xml:95(para)
+msgid "The first line tells us we are now four levels deep into the stack. Below it is a listing of the function calls that leads from here to gdk_pixbuf_new. Finally there is a list of functions that are at the next level down and call these functions. There are, of course, also entries for levels 1, 2, and 3, but this is the first level to reach right down through the GDK code to the <application>Same GNOME</application> code. From this listing, we can see instantly that the problem code is load_scenario."
+msgstr "První Å?ádek nám Å?íká, že jsme zanoÅ?ení do Ä?tvrté úrovnÄ? v zásobníku. Níže je seznam volání funkcí, které vedou odtud na gdk_pixbuf_new. Nakonec je zde seznam funkcí, které jsou o další úroveÅ? níže a volají tyto funkce. Jsou zde také samozÅ?ejmÄ?  položky pro úrovnÄ? 1, 2 a 3, ale toto je první úroveÅ?, která opravdu zasahuje pÅ?es kód GDK do kódu <application>Stejný GNOME</application>. Z tohoto seznamu můžeme ihned vidÄ?t, že problémovým kódem je load_scenario."
+
+#: C/optimization-massif.xml:98(para)
+msgid "Now that we know what part of our code is using all the spacetime we can look at it and find out why. It turns out that the load_scenario is loading a pixbuf from file and then never freeing that memory. Having identified the problem code, we can start to fix it."
+msgstr "Nyní, když víme, která Ä?ást naÅ¡eho kódu používá vÅ¡echen Ä?asoprostor, můžeme se na ni podívat a zjistit proÄ?. Ukáže se, že load_scenario naÄ?ítá pixbuf ze souboru a potom nikdy neuvolní pamÄ?Å¥. Tím mám zjiÅ¡tÄ?no, kde je v kódu problém a muže jej zaÄ?ít opravovat."
+
+#: C/optimization-massif.xml:103(title)
+msgid "Acting on the Results"
+msgstr "Využití výsledků"
+
+#: C/optimization-massif.xml:104(para)
+msgid "Reducing spacetime consumption is good, but there are two ways of reducing it and they are not equal. You can either reduce the amount of memory allocated, or reduce the amount of time it is allocated for. Consider for a moment a model system with only two processes running. Both processes use up almost all the physical RAM and if they overlap at all then the system will swap and everything will slow down. Obviously if we reduce the memory usage of each process by a factor of two then they can peacefully coexist without the need for swapping. If instead we reduce the time the memory is allocated by a factor of two then the two programs can coexist, but only as long as their periods of high memory use don't overlap. So it is better to reduce the amount of memory allocated."
+msgstr "Omezení spotÅ?eby Ä?asoprostoru je dobré, ale existují dva způsoby jak jej zredukovat a nejsou rovnocenné. BuÄ? můžete omezit množství alokované pamÄ?ti nebo omezit dobu, po kterou je alokováno. Na chvíli si pÅ?edstavte modelový systém, ve kterém bÄ?ží jen dva procesy. Oba procesy využívají témÄ?Å? vÅ¡echnu fyzickou pamÄ?Å¥ a když ji vyÄ?erpají celou, zaÄ?ne systém odkládat na disk a vÅ¡e se zpomalí. Je zjevné, že když omezíme použití pamÄ?ti rovnomÄ?rnÄ? každým z obou procesů, mohou klidnÄ? bÄ?žet naráz, aniž by bylo potÅ?eba odkládat na disk. Když místo toho omezíme Ä?as, po který je pamÄ?Å¥ alokována, rovnomÄ?rnÄ? u obou programů, mohou opÄ?t bÄ?žet v klidu souÄ?asnÄ?, ale jen ve chvílích, kdy se nesejdou jejich nejvÄ?tší požadavky na pamÄ?Å¥. Proto je lepší omezit množství alokované pamÄ?ti."
+
+#: C/optimization-massif.xml:107(para)
+msgid "Unfortunately, the choice of optimization is also constrained by the needs of the program. The size of the pixbuf data in <application>Same GNOME</application> is determined by the size of the game's graphics and cannot be easily reduced. However, the amount of time it spends loaded into memory can be drastically reduced. <xref linkend=\"optimization-massif-FIG-output-optimized\"/> shows the <application>Massif</application> analysis of <application>Same GNOME</application> after being altered to dispose of the pixbufs once the images have been loaded into the X server."
+msgstr "Bohužel je volba optimalizace odvislá i od potÅ?eb programu. Velikost dat pixbuf v aplikaci <application>Same GNOME</application> je dána velikostí grafiky hry a nelze ji jednoduÅ¡e zmenÅ¡it. Může být ale znaÄ?nÄ? omezeno množství Ä?asu, po který je naÄ?tena v pamÄ?ti. <xref linkend=\"optimization-massif-FIG-output-optimized\"/> ukazuje analýzu aplikací <application>Massif</application> pro program <application>Stejný GNOME</application> po úpravÄ? vedoucí k uvolnÄ?ní pixbuf, jakmile byly obrázky naÄ?teny na X server."
+
+#: C/optimization-massif.xml:111(title)
+msgid "<application>Massif</application> output for the optimized <application>Same GNOME</application> program."
+msgstr "Výstup z aplikace <application>Massif</application> pro optimalizovanou verzi prgramu <application>Stejný GNOME</application>."
+
+#: C/optimization-massif.xml:118(para)
+msgid "The spacetime use of gdk_pixbuf_new is now a thin band that only spikes briefly (it is now the sixteenth band down and shaded magenta). As a bonus, the peak memory use has dropped by 200 kB since the spike occurs before other memory is allocated. If two processes like this where run together the chances of the peak memory usage coinciding, and hence the risk of swapping, would be quite low."
+msgstr "Využití Ä?asoprostoru funkcí gdk_pixbuf_new pÅ?edstavuje nyní tenÄ?í pás, který jen zÅ?ídka povyskoÄ?í (je teÄ? o Å¡estnáct pozic níž a vyplnÄ?ný purpurovou barvou). Jako bonus poklesl Å¡piÄ?kový odbÄ?r pamÄ?ti o 200 kB, protože Å¡piÄ?ka se objeví pÅ?ed dalšími alokacemi pamÄ?ti. Pokud bÄ?ží naráz dva takové podobné procesy, je Å¡ance, že takové dvÄ? pamÄ?Å¥ové Å¡piÄ?ky nastanou naráz, a tím vznikne riziko odkládání na disk, docela malá."
+
+#: C/optimization-massif.xml:121(para)
+msgid "Can we do better ? A quick examination of <application>Massif</application>'s text output reveals: g_strdup to be the new major offender."
+msgstr "Můžeme to udÄ?lat lépe? Rychlý průzkum textového výstupu <application>Massif</application> odhalí že: nový hlavní viník je g_strdup."
+
+#: C/optimization-massif.xml:124(programlisting)
+#, no-wrap
+msgid ""
+"\n"
+"Command: ./same-gnome \n"
+"\n"
+"== 0 ===========================\n"
+"Heap allocation functions accounted for 87.6% of measured spacetime\n"
+"\n"
+"Called from:\n"
+"    7.7% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)\n"
+"\n"
+"    7.6% : 0x43BC9F: (within /usr/lib/libgdk-x11-2.0.so.0.400.9)\n"
+"\n"
+"    6.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)\n"
+"\n"
+"    5.2% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)\n"
+"        "
+msgstr ""
+"\n"
+"PÅ?íkaz: ./same-gnome \n"
+"\n"
+"== 0 ===========================\n"
+"Funkce pro alokaci haldy zodpovídají za 87,6% mÄ?Å?eného Ä?asoprostoru\n"
+"\n"
+"Voláno z:\n"
+"    7.7% : 0x5A32A5: g_strdup (v /usr/lib/libglib-2.0.so.0.400.6)\n"
+"\n"
+"    7.6% : 0x43BC9F: (uvnitÅ? /usr/lib/libgdk-x11-2.0.so.0.400.9)\n"
+"\n"
+"    6.9% : 0x510B3C: (uvnitÅ? /usr/lib/libfreetype.so.6.3.7)\n"
+"\n"
+"    5.2% : 0x2A4A6B: __gconv_open (v /lib/tls/libc-2.3.3.so)\n"
+"        "
+
+#: C/optimization-massif.xml:139(para)
+msgid "If we look closer though we see that it is called from many, many, places."
+msgstr "Když se na to podíváme blíže, uvidíme, že je volán na mnoha, opravdu mnoha místech."
+
+#: C/optimization-massif.xml:142(programlisting)
+#, no-wrap
+msgid ""
+"\n"
+"== 1 ===========================\n"
+"Context accounted for  7.7% of measured spacetime\n"
+"  0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)\n"
+"\n"
+"Called from:\n"
+"    1.8% : 0x8BF606: gtk_icon_source_copy (in /usr/lib/libgtk-x11-2.0.so.0.400.9)\n"
+"\n"
+"    1.1% : 0x67AF6B: g_param_spec_internal (in /usr/lib/libgobject-2.0.so.0.400.6)\n"
+"\n"
+"    0.9% : 0x91FCFC: (within /usr/lib/libgtk-x11-2.0.so.0.400.9)\n"
+"\n"
+"    0.8% : 0x57EEBF: g_quark_from_string (in /usr/lib/libglib-2.0.so.0.400.6)\n"
+"\n"
+"  and 155 other insignificant places\n"
+"        "
+msgstr ""
+"\n"
+"== 1 ===========================\n"
+"Kontext zodpovídá za 7,7% mÄ?Å?eného Ä?asového prostoru\n"
+"  0x5A32A5: g_strdup (v /usr/lib/libglib-2.0.so.0.400.6)\n"
+"\n"
+"Called from:\n"
+"    1.8% : 0x8BF606: gtk_icon_source_copy (v /usr/lib/libgtk-x11-2.0.so.0.400.9)\n"
+"\n"
+"    1.1% : 0x67AF6B: g_param_spec_internal (v /usr/lib/libgobject-2.0.so.0.400.6)\n"
+"\n"
+"    0.9% : 0x91FCFC: (uvnitÅ? /usr/lib/libgtk-x11-2.0.so.0.400.9)\n"
+"\n"
+"    0.8% : 0x57EEBF: g_quark_from_string (v /usr/lib/libglib-2.0.so.0.400.6)\n"
+"\n"
+"  a 155 dalších nedůležitých míst\n"
+"        "
+
+#: C/optimization-massif.xml:158(para)
+msgid "We now face diminishing returns for our optimization efforts. The graph hints at another possible approach: Both the \"other\" and \"heap admin\" bands are quite large. This tells us that there are a lot of small allocations are being made from a variety of places. Eliminating these will be difficult, but if they can be grouped then the individual allocations can be larger and the \"heap admin\" overhead can be reduced."
+msgstr "Nyní stojíme oproti klesající návratnost naší snahy o optimalizaci. Graf nám poradí jiný možný pÅ?ístup: Pásy â??ostatníâ?? a â??správa haldyâ?? jsou docela velké. To nám Å?íká, že je zde spousta malých alokací provádÄ?ných na různých místech. OdstranÄ?ní nÄ?Ä?eho takového může být obtížné, ale když je slouÄ?íme do jediné alokace, může být vÄ?tší a â??správa haldyâ?? se tím zmenší."
+
+#: C/optimization-massif.xml:163(title)
+msgid "Caveats"
+msgstr "UpozornÄ?ní"
+
+#: C/optimization-massif.xml:164(para)
+msgid "There are a couple of things to watch out for: Firstly, spacetime is only reported as a percentage, you have to compare it to the overall size of the program to decide if the amount of memory is worth pursuing. The graph, with its kilobyte vertical axis, is good for this."
+msgstr "Je zde pár vÄ?cí, na které je tÅ?eba si dávat pozor: Zaprvé, Ä?asové úseky jsou uvádÄ?ny jako procentuální Ä?ást, musíte je vztáhnout na celkovou velikost programu, abyste mohli usoudit, zda množství pamÄ?ti stojí za sledování. Dobrý je k tomu graf s hodnotami v kilobajtech na svislé ose."
+
+#: C/optimization-massif.xml:167(para)
+msgid "Secondly, <application>Massif</application> only takes into account the memory used by your own program. Resources like pixmaps are stored in the X server and aren't considered by <application>Massif</application>. In the <application>Same GNOME</application> example we have actually only moved the memory consumption from client-side pixbufs to server-side pixmaps. Even though we cheated there are performance gains. Keeping the image data in the X server makes the graphics routines quicker and removes a lot of inter-process communication. Also, the pixmaps will be stored in a native graphics format which is often more compact than the 32-bit RGBA format used by gdk_pixbuf. To measure the effect of pixmaps, and other X resources use the <ulink type=\"http\" url=\"http://www.freedesktop.org/Software/xrestop\";>xrestop</ulink> program."
+msgstr "Zadruhé, aplikace <application>Massif</application> bere v úvahu jen pamÄ?Å¥ použitou vaÅ¡im vlastním programem. Zdroje jako pixelové mapy jsou uložené na X serveru a aplikace <application>Massif</application> je nebere v úvahu. V ukázkovém programu <application>Stejný GNOME</application> máme právÄ? jen pÅ?esuny spotÅ?eby pamÄ?ti ze strany klienta do pixelových map na stranÄ? serveru. Dokonce je tu nárůst výkonu, pÅ?estože tím vlastnÄ? Å¡vindlujeme. Uchováním obrazových dat na X serveru grafické rutiny zrychluje a odstraÅ?uje spoustu meziprocesové komunikace. Mimo to jsou pixelové mapy uchované v nativním grafickém formátu, který je povÄ?tÅ¡inou více kompaktní než 32bitový RGBA formát používaný u gdk_pixbuf. K mÄ?Å?ení úÄ?innosti pixelových map a ostatních zdrojů X serveru použijte program <ulink type=\"http\" url=\"http://www.freedesktop.org/Software/xrestop\";>xrestop</ulink>."
+
+#: C/optimization-harmful.xml:3(title)
+msgid "Disk Seeks Considered Harmful"
+msgstr "Nastavení hlaviÄ?ek disku má neblahý vliv"
+
+#: C/optimization-harmful.xml:5(para)
+msgid "Disk seeks are one of the most expensive operations you can possibly perform. You might not know this from looking at how many of them we perform, but trust me, they are. Consequently, please refrain from the following suboptimal behavior:"
+msgstr "Natavení hlaviÄ?ek disku je jedna z Ä?asovÄ? nejnákladnÄ?jších operací, které jen můžete provádÄ?t. Možná byste viditelnÄ? nepoznali jak Ä?asto se provádí, ale vÄ?Å?te že se dÄ?lá. V důsledku toho se prosím vyhnÄ?te následujícímu ne zrovna optimálnímu chování:"
+
+#: C/optimization-harmful.xml:10(para)
+msgid "Placing lots of small files all over the disk."
+msgstr "Umisťování velkého množství malých souborů po celém disku."
+
+#: C/optimization-harmful.xml:15(para)
+msgid "Opening, stating, and reading lots of files all over the disk"
+msgstr "Otevírání, zjiÅ¡Å¥ování stavu a Ä?tení velkého množství souborů po celém disku."
+
+#: C/optimization-harmful.xml:20(para)
+msgid "Doing the above on files that are laid out at different times, so as to ensure that they are fragmented and cause even more seeking."
+msgstr "ProvádÄ?ní pÅ?edchozích vÄ?cí na souborech, které byly ukládány v různou dobu a tím pádem jsou nejspíše fragmentované a požadují nastavení hlaviÄ?ek disku."
+
+#: C/optimization-harmful.xml:25(para)
+msgid "Doing the above on files that are in different directories, so as to ensure that they are in different cylinder groups and and cause even more seeking."
+msgstr "ProvádÄ?ní pÅ?edchozích vÄ?cí na souborech, které jsou v různých složkách, tím pádem urÄ?itÄ? na různých skupinách cylindrů, což způsobí další nastavení hlaviÄ?ek disku."
+
+#: C/optimization-harmful.xml:30(para)
+msgid "Repeatedly doing the above when it only needs to be done once."
+msgstr "Opakované dÄ?lání vÄ?cí uvedených v pÅ?edchozím, když je staÄ?í udÄ?lat jednou."
+
+#: C/optimization-harmful.xml:35(para)
+msgid "Ways in which you can optimize your code to be seek-friendly:"
+msgstr "Cesty, kterými můžete optimalizovat svůj kód, aby minimalizoval nastavení hlaviÄ?ek disku:"
+
+#: C/optimization-harmful.xml:40(para)
+msgid "Consolidate data into a single file."
+msgstr "SluÄ?te data do jednoho souboru."
+
+#: C/optimization-harmful.xml:45(para)
+msgid "Keep data together in the same directory."
+msgstr "Udržujte data dohromady ve stejné složce."
+
+#: C/optimization-harmful.xml:50(para)
+msgid "Cache data so as to not need to reread constantly."
+msgstr "Ukládejte data do mezipamÄ?ti, aby je nebylo potÅ?eba Ä?íst stále dokola."
+
+#: C/optimization-harmful.xml:55(para)
+msgid "Share data so as not to have to reread it from disk when each application loads."
+msgstr "Sdílejte data tak, aby nemusela být znovu Ä?tena z disku, když je chce každá z aplikací naÄ?íst."
+
+#: C/optimization-harmful.xml:60(para)
+msgid "Consider caching all of the data in a single binary file that is properly aligned and can be mmaped."
+msgstr "Zvažte ukládání vÅ¡ech dat do mezipamÄ?ti v podobÄ? jednoho binárního souboru, který je správnÄ? zarovnán a lze pro nÄ?j použít mmap."
+
+#: C/optimization-harmful.xml:65(para)
+msgid "The trouble with disk seeks are compounded for reads, which is unfortunately what we are doing. Remember, reads are generally synchronous while writes are asynchronous. This only compounds the problem, serializing each read, and contributing to program latency."
+msgstr "Problémy s nastavením hlaviÄ?ek disku jsou složité hlavnÄ? pro Ä?tení, což je bohužel pÅ?esnÄ? to co dÄ?láme. Pamatujte, že Ä?tení je obecnÄ? synchronní, zatímco zápis asynchronní. To problém jen komplikuje, serializuje každé Ä?tení a pÅ?ispívá k prodlouženým odezvám programu"
+
+#: C/optimization-guide.xml:5(title)
+msgid "Optimizing GNOME Software"
+msgstr "Optimalizace softwaru GNOME"
+
+#: C/optimization-guide.xml:8(publishername)
+#: C/optimization-guide.xml:56(para)
+msgid "GNOME Documentation Project"
+msgstr "DokumentaÄ?ní projekt GNOME"
+
+#: C/optimization-guide.xml:11(year)
+#: C/optimization-guide.xml:15(year)
+msgid "2004-2005"
+msgstr "2004-2005"
+
+#: C/optimization-guide.xml:12(holder)
+msgid "Callum McKenzie"
+msgstr "Callum McKenzie"
+
+#: C/optimization-guide.xml:16(holder)
+msgid "Robert Love"
+msgstr "Robert Love"
+
+#: C/optimization-guide.xml:20(firstname)
+msgid "Callum"
+msgstr "Callum"
+
+#: C/optimization-guide.xml:21(surname)
+msgid "McKenzie"
+msgstr "McKenzie"
+
+#: C/optimization-guide.xml:24(firstname)
+msgid "Robert"
+msgstr "Robert"
+
+#: C/optimization-guide.xml:25(surname)
+msgid "Love"
+msgstr "Love"
+
+#: C/optimization-guide.xml:29(para)
+msgid "Permission is granted to copy, distribute and/or modify this document under the terms of the <citetitle>GNU Free Documentation License</citetitle>, Version 1.1 or any later version published by the Free Software Foundation with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. You may obtain a copy of the <citetitle>GNU Free Documentation License</citetitle> from the Free Software Foundation by visiting <ulink type=\"http\" url=\"http://www.fsf.org\";>their Web site</ulink> or by writing to: Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA."
+msgstr "Je povoleno kopírovat, šíÅ?it a/nebo upravovat tento dokument za podmínek <citetitle>GNU Free Documentation License</citetitle>, verze 1.1 nebo jakékoli další verze vydané nadací Free Software Foundation; bez nemÄ?nných oddílů, bez textů pÅ?edních desek a bez textů zadních desek. Kopii licence <citetitle>GNU Free Documentation License</citetitle> od Free Software Foundation můžete získat navÅ¡tívením <ulink type=\"http\" url=\"http://www.fsf.org\";>webových stránek</ulink> nebo když si napíšete na: Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA."
+
+#: C/optimization-guide.xml:41(para)
+msgid "Many of the names used by companies to distinguish their products and services are claimed as trademarks. Where those names appear in any GNOME documentation, and those trademarks are made aware to the members of the GNOME Documentation Project, the names have been printed in caps or initial caps."
+msgstr "Mnoho užívaných jmen urÄ?ených k zviditelnÄ?ní produktů nebo služeb jsou ochranné známky. Na místech, kde jsou tato jména v dokumentaci užita a Ä?lenové DokumentaÄ?ního projektu GNOME jsou si vÄ?domi skuteÄ?nosti, že se jedná o ochrannou známku, je takové jméno psáno velkými písmeny celé nebo s velkým písmenem na zaÄ?átku."
+
+#: C/optimization-guide.xml:52(revnumber)
+msgid "0.1"
+msgstr "0.1"
+
+#: C/optimization-guide.xml:53(date)
+msgid "November 2007"
+msgstr "Prosinec 2007"
+
+#: C/optimization-guide.xml:55(para)
+msgid "William Johnston"
+msgstr "William Johnston"
+
+#: C/optimization-guide.xml:57(para)
+msgid "Intial conversion to docbook format."
+msgstr "PoÄ?áteÄ?ní pÅ?evod do formátu docbook"
+
+#: C/optimization-guide.xml:63(para)
+msgid "Software can be optimized in many ways: for speed, program size, or memory use. This section contains guides and tutorials for optimizing your software."
+msgstr "Software je možné optimalizovat z Å?ady důvodů: na rychlost, na velikost programu nebo využití pamÄ?ti. Tento oddíl obsahuje pÅ?íruÄ?ku a průvodce pro optimalizaci vaÅ¡eho softwaru."
+
+#. Put one translator per line, in the form of NAME <EMAIL>, YEAR1, YEAR2
+#: C/optimization-guide.xml:0(None)
+msgid "translator-credits"
+msgstr "Marek Ä?ernocký, 2010"
+
diff --git a/optimization-guide/cs/figures/massif-after.png b/optimization-guide/cs/figures/massif-after.png
new file mode 100644
index 0000000..1bce70c
Binary files /dev/null and b/optimization-guide/cs/figures/massif-after.png differ
diff --git a/optimization-guide/cs/figures/massif-before.png b/optimization-guide/cs/figures/massif-before.png
new file mode 100644
index 0000000..52e0578
Binary files /dev/null and b/optimization-guide/cs/figures/massif-before.png differ