[gnome-devel-docs] Added initial Spanish translation

[Jorge Gonzalez Gonzalez <jorgegonz src gnome org>]

commit 8a4ad1ba43fde33f8f31793547b91374bcb9d214
Author: Jorge González <jorgegonz svn gnome org>
Date:   Wed Sep 30 00:42:19 2009 +0200

    Added initial Spanish translation

 optimization-guide/es/es.po |  877 +++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 877 insertions(+), 0 deletions(-)
---
diff --git a/optimization-guide/es/es.po b/optimization-guide/es/es.po
new file mode 100644
index 0000000..d2a0d41
--- /dev/null
+++ b/optimization-guide/es/es.po
@@ -0,0 +1,877 @@
+# translation of gnome-devel-docs.optimization-guide.master.po to Español
+# Spanish 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.
+#
+# Jorge Gonzalez <jorgegonz svn gnome org>, 2009.
+msgid ""
+msgstr ""
+"Project-Id-Version: gnome-devel-docs.optimization-guide.master\n"
+"POT-Creation-Date: 2009-09-29 19:58+0000\n"
+"PO-Revision-Date: 2009-09-30 00:40+0200\n"
+"Last-Translator: Jorge Gonzalez <jorgegonz svn gnome org>\n"
+"Language-Team: Español <gnome-es-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=2; plural=(n != 1);\n"
+"X-Generator: KBabel 1.11.4\n"
+
+#: C/optimization-intro.xml:3(title)
+msgid "The Quick Guide to Optimizing GNOME Programs"
+msgstr "Guía rápida para optimizar programas de 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 ""
+
+#: C/optimization-intro.xml:10(title)
+msgid "What are we Optimizing?"
+msgstr "¿Qué se está optimizando?"
+
+#: 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 ""
+
+#: 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 "Realizar la optimización"
+
+#: 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 "Sugerencias"
+
+#: C/optimization-intro.xml:43(title)
+msgid "The Fundamentals"
+msgstr "Lo fundamental"
+
+#: 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 "Optimizar al nivel más alto antes de optimizar los detalles."
+
+#: 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 ""
+
+#: 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 "Consejos de bajo nivel"
+
+#: 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 ""
+
+#: 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 ""
+
+#: C/optimization-intro.xml:142(title)
+msgid "High Level Tricks"
+msgstr "Trucos de alto nivel"
+
+#: 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 "@@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 "Usar <application>Massif</application> para el Perfilado del uso de memoria en software de 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 ""
+
+#: C/optimization-massif.xml:10(title)
+msgid "Introduction"
+msgstr "Introducción"
+
+#: 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 "Usar <application>Massif</application> con 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 ""
+
+#: 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 "Su línea de comando debería parecerse a esta:"
+
+#: 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 ""
+
+#: C/optimization-massif.xml:41(title)
+msgid "Interpreting the Results"
+msgstr "Interpretar los resultados"
+
+#: 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 ""
+"La salida de <application>Massif</application> para la versión no optimizada del programa "
+"<application>Same 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 ""
+
+#: 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 ""
+
+#: 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 "Actuar sobre los resultados"
+
+#: 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 ""
+"La salida de <application>Massif</application> para el programa optimizado "
+"<application>Same 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 ""
+
+#: 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 ""
+
+#: 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 "Optimizar software de GNOME"
+
+#: C/optimization-guide.xml:8(publishername) C/optimization-guide.xml:56(para)
+msgid "GNOME Documentation Project"
+msgstr "Proyecto de documentación de 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 ""
+"Se otorga permiso para copiar, distribuir y/o modificar este documento bajo "
+"los términos de la <citetitle>Licencia de Documentación Libre de GNU</citetitle>, "
+"Versión 1.1 o cualquier otra versión posterior publicada por la Free Software Foundation; "
+"sin Secciones Invariantes ni Textos de Cubierta Delantera ni Textos de "
+"Cubierta Trasera. Puede encontrar una copia de la licencia <citetitle>Licencia de "
+"Documentación Libre de GNU</citetitle> de la Free Software Foundation visitando "
+"ulink type=\"http\" url=\"http://www.fsf.org\";>su página web</ulink> o escribiendo a: "
+"Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-"
+"1307, EE. UU."
+
+#: 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 ""
+"Muchos de los nombres usados por compañías para distinguir sus productos y "
+"servicios se mencionan como marcas comerciales. Donde aparezcan dichos "
+"nombres en cualquier documentación GNOME, y para que los miembros del "
+"proyecto de documentación las reconozcan dichas marcas comerciales, dichos "
+"nombres se imprimen en mayúsculas o iniciales mayúsculas."
+
+#: C/optimization-guide.xml:52(revnumber)
+msgid "0.1"
+msgstr "0.1"
+
+#: C/optimization-guide.xml:53(date)
+msgid "November 2007"
+msgstr "Noviembre de 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 "Conversión inicial al formato 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 ""
+"El software se puede optimizar de muchas formas: para mayor velocidad, tamaño del programa o "
+"uso de memoria. Esta sección contiene guías y tutoriales para optimizar su software."
+
+#. Put one translator per line, in the form of NAME <EMAIL>, YEAR1, YEAR2
+#: C/optimization-guide.xml:0(None)
+msgid "translator-credits"
+msgstr "Jorge González <jorgegonz svn gnome org>, 2009"
+