[gnome-devel-docs] Added German doc translation

[Mario Blättermann <mariobl src gnome org>]

commit 6cda30e95d2b9ff92e849d1bd122131da39ffed8
Author: Mario Blättermann <mariobl gnome org>
Date:   Tue Sep 29 21:57:48 2009 +0200

    Added German doc translation

 optimization-guide/Makefile.am |    2 +-
 optimization-guide/de/de.po    |  917 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 918 insertions(+), 1 deletions(-)
---
diff --git a/optimization-guide/Makefile.am b/optimization-guide/Makefile.am
index 5411da5..2eb74ac 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 =
+DOC_LINGUAS = de
 DOC_ENTITIES =
 DOC_INCLUDES = \
   optimization-harmful.xml \
diff --git a/optimization-guide/de/de.po b/optimization-guide/de/de.po
new file mode 100644
index 0000000..7277ba0
--- /dev/null
+++ b/optimization-guide/de/de.po
@@ -0,0 +1,917 @@
+# German translation for gnome-devel-docs.
+# Copyright (C) 2009 gnome-devel-docs's COPYRIGHT HOLDER
+# This file is distributed under the same license as the gnome-devel-docs package.
+# Mario Blättermann <mariobl gnome org>, 2009.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: gnome-devel-docs master\n"
+"POT-Creation-Date: 2009-09-29 18:19+0000\n"
+"PO-Revision-Date: 2009-09-29 21:52+0100\n"
+"Last-Translator: Mario Blättermann <mariobl gnome org>\n"
+"Language-Team: German <gnome-de gnome org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=2; plural=(n != 1);\n"
+"X-Poedit-Language: German\n"
+"X-Poedit-Country: GERMANY\n"
+
+#: C/optimization-intro.xml:3(title)
+msgid "The Quick Guide to Optimizing GNOME Programs"
+msgstr "Schnelleinführung in die Optimierung von GNOME-Programmen"
+
+#: 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 ""
+
+#: C/optimization-intro.xml:10(title)
+msgid "What are we Optimizing?"
+msgstr "Was optimieren wir?"
+
+#: 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 ""
+"Sie sollten bei der Optimierung für GNOME zunächst eines bedenken: Wir "
+"versuchen nicht, das Programm zu verbessern, sondern wir versuchen, die "
+"Benutzer glücklicher zu machen."
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-intro.xml:23(title)
+msgid "Doing the Optimization"
+msgstr "Ausführung der Optimierung"
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-intro.xml:41(title)
+msgid "Hints"
+msgstr ""
+
+#: C/optimization-intro.xml:43(title)
+msgid "The Fundamentals"
+msgstr "Die Grundlagen"
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-intro.xml:55(para)
+msgid "Optimize at the high level before optimizing the details."
+msgstr ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-intro.xml:81(title)
+msgid "Traps for the Unwary"
+msgstr "Fallen für die Unvorsichtigen"
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-intro.xml:104(title)
+msgid "Low Level Hints"
+msgstr ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+"Verwenden Sie keine Assemblersprachen. Sie sind nicht portierbar. Während sie "
+"auf dem einen Prozessor unglaublich schnell sind, ist nicht unbedingt "
+"garantiert, dass dies auf jedem von der Architektur unterstützten Prozessor "
+"genauso ist (beispielsweise 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 ""
+
+#: 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 ""
+"Halten Sie die Zahl der verlinkten Bibliotheken gering. Je weniger "
+"Bibliotheken gelinkt werden müssen, umso schneller startet das Programm. Dies "
+"ist in GNOME allerdings schwierig."
+
+#: C/optimization-intro.xml:142(title)
+msgid "High Level Tricks"
+msgstr ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+
+#. 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 ""
+
+#. 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 ""
+
+#: C/optimization-massif.xml:3(title)
+msgid ""
+"Using <application>Massif</application> for Profiling Memory Use in GNOME "
+"Software"
+msgstr ""
+
+#: 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 ""
+
+#: C/optimization-massif.xml:10(title)
+msgid "Introduction"
+msgstr "Einführung"
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-massif.xml:22(title)
+msgid "Using <application>Massif</application> with GNOME"
+msgstr ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-massif.xml:29(para)
+msgid "Your command-line should therefore look something like:"
+msgstr ""
+
+#: 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 ""
+"Das Programm <application>Same GNOME</application> werden wir als Beispiel "
+"verwenden. Seien Sie gewarnt: <application>Valgrind</application> emuliert "
+"den Prozessor, wodurch es <emphasis>äu�erst</emphasis> langsam läuft. "
+"Au�erdem wird sehr viel Speicher benötigt."
+
+#: C/optimization-massif.xml:41(title)
+msgid "Interpreting the Results"
+msgstr "Interpretieren der Ergebnisse"
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-massif.xml:49(title)
+msgid ""
+"<application>Massif</application> output for the unoptimized version of the "
+"<application>Same GNOME</application> program."
+msgstr ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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"
+"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"
+"        "
+
+#: 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 ""
+
+#: 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"
+"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"
+"        "
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-massif.xml:103(title)
+msgid "Acting on the Results"
+msgstr ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-massif.xml:111(title)
+msgid ""
+"<application>Massif</application> output for the optimized <application>Same "
+"GNOME</application> program."
+msgstr ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: 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"
+"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"
+"        "
+
+#: C/optimization-massif.xml:139(para)
+msgid ""
+"If we look closer though we see that it is called from many, many, places."
+msgstr ""
+
+#: 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"
+"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"
+"        "
+
+#: 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 ""
+
+#: C/optimization-massif.xml:163(title)
+msgid "Caveats"
+msgstr ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-harmful.xml:3(title)
+msgid "Disk Seeks Considered Harmful"
+msgstr ""
+
+#: 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 ""
+
+#: C/optimization-harmful.xml:10(para)
+msgid "Placing lots of small files all over the disk."
+msgstr ""
+
+#: C/optimization-harmful.xml:15(para)
+msgid "Opening, stating, and reading lots of files all over the disk"
+msgstr ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-harmful.xml:30(para)
+msgid "Repeatedly doing the above when it only needs to be done once."
+msgstr ""
+
+#: C/optimization-harmful.xml:35(para)
+msgid "Ways in which you can optimize your code to be seek-friendly:"
+msgstr ""
+
+#: C/optimization-harmful.xml:40(para)
+msgid "Consolidate data into a single file."
+msgstr ""
+
+#: C/optimization-harmful.xml:45(para)
+msgid "Keep data together in the same directory."
+msgstr ""
+
+#: C/optimization-harmful.xml:50(para)
+msgid "Cache data so as to not need to reread constantly."
+msgstr ""
+
+#: C/optimization-harmful.xml:55(para)
+msgid ""
+"Share data so as not to have to reread it from disk when each application "
+"loads."
+msgstr ""
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-guide.xml:5(title)
+msgid "Optimizing GNOME Software"
+msgstr "Optimieren von GNOME-Software"
+
+#: C/optimization-guide.xml:8(publishername) C/optimization-guide.xml:56(para)
+msgid "GNOME Documentation Project"
+msgstr "GNOME-Dokumentationsprojekt"
+
+#: 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 ""
+"Das vorliegende Dokument kann gemä� den Bedingungen der GNU Free "
+"Documentation License (GFDL), Version 1.1 oder jeder späteren, von der Free "
+"Software Foundation veröffentlichten Version ohne unveränderbare Abschnitte "
+"sowie ohne Texte auf dem vorderen und hinteren Buchdeckel kopiert, verteilt "
+"und/oder modifiziert werden. Eine Kopie der GFDL finden Sie unter diesem "
+"<ulink type=\"help\" url=\"ghelp:fdl\">Link</ulink> oder in der mit diesem "
+"Handbuch gelieferten Datei COPYING-DOCS."
+
+#: 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 ""
+"Bei vielen der von Firmen zur Unterscheidung ihrer Produkte und "
+"Dienstleistungen verwendeten Namen handelt es sich um Marken. An den Stellen, "
+"an denen derartige Namen in einer GNOME-Dokumentation vorkommen und wenn die "
+"Mitglieder des GNOME-Dokumentationsprojekts über diese Marken informiert "
+"wurden, sind die Namen in GroÃ?buchstaben oder mit groÃ?en Anfangsbuchstaben "
+"geschrieben."
+
+#: C/optimization-guide.xml:52(revnumber)
+msgid "0.1"
+msgstr "0.1"
+
+#: C/optimization-guide.xml:53(date)
+msgid "November 2007"
+msgstr "November 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 "Erstmalige Umwandlung in das DocBook-Format."
+
+#: 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 ""
+"Die Optimierung von Software kann verschiedene Ziele verfolgen: "
+"Geschwindigkeit, Programmgrö�e oder Speicherverbrauch. Dieser Abschnitt "
+"enthält Leitfäden und Anleitungen zum Optimieren Ihrer Software."
+
+#. Put one translator per line, in the form of NAME <EMAIL>, YEAR1, YEAR2
+#: C/optimization-guide.xml:0(None)
+msgid "translator-credits"
+msgstr "Mario Blättermann <mariobl gnome org>, 2009"