gnome-devel-docs.optimization-guide.master - en to es_ES translation catalogue (88 entries)

note: (itstool) path: page/title
en: Disk Seeks Considered Harmful
es_ES: Búsquedas de disco consideradas dañinas

note: (itstool) path: page/p (itstool) path: section/p
en: 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:
es_ES: Las búsquedas de disco son una de las operaciones más caras que puede realizar. Puede que no sepa esto simplemente mirando cuántas se realizan, pero crea que realmente lo son. Por ello, evite los siguientes comportamientos:

note: (itstool) path: item/p
en: Placing lots of small files all over the disk.
es_ES: Ubicar montones de pequeños archivos por todo el disco.

note: (itstool) path: item/p
en: Opening, stating, and reading lots of files all over the disk
es_ES: Abrir, iniciar y leer montones de archivos por todo el disco.

note: (itstool) path: item/p
en: 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.
es_ES: Realizar lo anterior sobre archivos que se abren en diferentes momentos, para asegurarse de que están fragmentados y causan aún más búsqueda del disco.

note: (itstool) path: item/p
en: Doing the above on files that are in different directories, so as to ensure that they are in different cylinder groups and cause even more seeking.
es_ES: Realizar lo siguiente sobre archivos que están en diferentes carpetas, para asegurarse de que están en grupos de cilindros diferentes y pueden causar incluso más búsqueda.

note: (itstool) path: item/p
en: Repeatedly doing the above when it only needs to be done once.
es_ES: Realizar repetidamente lo anterior cuando sólo se necesita realizar una vez.

note: (itstool) path: page/p
en: Ways in which you can optimize your code to be seek-friendly:
es_ES: Formas en las que puede optimizar su código para que sea amigable a la hora de hacer búsquedas:

note: (itstool) path: item/p
en: Consolidate data into a single file.
es_ES: Consolidar los datos en un solo archivo.

note: (itstool) path: item/p
en: Keep data together in the same directory.
es_ES: Mantener los datos juntos en la mismo carpeta.

note: (itstool) path: item/p
en: Cache data so as to not need to reread constantly.
es_ES: Cachear los datos para no tener que volver a leerlos constantemente.

note: (itstool) path: item/p
en: Share data so as not to have to reread it from disk when each application loads.
es_ES: Compartir los datos para no tener que volver a leerlos del disco cada vez que una aplicación se carga.

note: (itstool) path: item/p
en: Consider caching all of the data in a single binary file that is properly aligned and can be mmapped.
es_ES: Considerar cachear todos los datos en un archivo binario único que está alineado apropiadamente y se puede mapear.

note: (itstool) path: page/p
en: 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.
es_ES: El problema de las búsquedas en los discos se complica para las lecturas, que es desafortunadamente lo que se busca. Recuerde, las lecturas son generalmente síncronas mientras que las escrituras son asíncronas. Esto sólo complica el problema, serializando cada lectura y contribuyendo a la latencia del programa.

note: (itstool) path: license/p
en: Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, 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 GNU Free Documentation License from the Free Software Foundation by visiting <link href="http://www.fsf.org">their Web site</link> or by writing to: Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor Boston, MA 02110-1335, USA.
es_ES: Se otorga permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de Documentación Libre de GNU, 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 Licencia de Documentación Libre de GNU de la Free Software Foundation visitando <link href="http://www.fsf.org">su página web</link> o escribiendo a: Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor Boston, MA 02110-1335, USA.

note: (itstool) path: license/p
en: 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.
es_ES: 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.

note: (itstool) path: info/desc
en: Software can be optimized in many ways: for speed, program size, or memory use. This section contains guides and tutorials for optimizing your software.
es_ES: 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.

note: (itstool) path: page/title
en: Optimization Guide
es_ES: Guía de optimización

note: (itstool) path: section/title
en: Introduction
es_ES: Introducción

note: (itstool) path: section/p
en: 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.
es_ES: Esta es una breve introducción a la optimización, tanto de los «cómos» como de los «porqués». Se dejan para posteriores artículos los detalles de herramientas y técnicas individuales pero se proporciona una colección de sugerencias y trucos.

note: (itstool) path: section/p (itstool) path: page/p
en: This article describes how to use the <app>Massif</app> heap profiler with GNOME applications. We describe how to invoke, interpret, and act on the output of <app>Massif</app>. The <app>Swell Foop</app> game is used as an example.
es_ES: Este artículo describe cómo usar el perfilador <app>Massif</app> con las aplicaciones de GNOME. Describe cómo invocar, interpretar y actuar sobre la salida de <app>Massif</app>. Se usa el juego <app>Swell Foop</app> como ejemplo.

note: (itstool) path: section/title
en: Harmfulness
es_ES: Nocividad

note: (itstool) path: page/title
en: What are we Optimizing?
es_ES: ¿Qué se está optimizando?

note: (itstool) path: page/p
en: 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.
es_ES: Al optimizar GNOME lo primero que hay que recordar es esto: no se está intentando mejorar el programa, se está intentando hacer que las personas usen el equipo más felices.

note: (itstool) path: page/p
en: 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.
es_ES: Programas mejores hacen a la gente más feliz pero existen algunas mejoras que los harán más felices que otras: tiempo de respuesta, tiempo de inicio, facilidad para acceder a comandos y que el equipo no tenga que usar la memoria de intercambio cuando más de dos programas estén abiertos.

note: (itstool) path: page/p
en: 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.
es_ES: La optimización tradicional contempla conceptos como el uso de CPI, el tamaño del código, el número de pulsaciones del ratón y el uso de memoria de programa. Se ha elegido esta segunda lista para correlar con la primera, no obstante existe una diferencia importante. A la persona que usa GNOME no le importa la segunda lista, pero sí la primera. Al optimizar los programas de GNOME se reducirá el uso de CPU, el uso de memoria y todo aquello, pero son conceptos para el fin, no el objetivo final. Se optimiza para las personas.

note: (itstool) path: section/title
en: Doing the Optimization
es_ES: Realizar la optimización

note: (itstool) path: section/p
en: 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.
es_ES: En la sección anterior se omitió un calificador importante: optimizar algo debe ser medible. No se puede medir la felicidad. No obstante se puede medir el tiempo de inicio de un programa para saber si se ha mejorado. La felicidad del usuario aumentará pues.

note: (itstool) path: section/p
en: 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 <em>should</em> be fast and a program that <em>is</em> fast.
es_ES: La optimización es el proceso de medida, refinamiento y remedida. Lo primero que debe hacer es encontrar una forma de medir lo que está optimizando. Idealmente la medida es un simple número, por ejemplo: el tiempo que se tarda en realizar una tarea. Esta es su prueba, es la única forma de saber si está ganando o perdiendo. Existe una gran diferencia entre un programa que <em>debería</em> ser rápido y un programa que <em>es</em> rápido.

note: (itstool) path: section/p
en: 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.
es_ES: Una vez que tiene una prueba de rendimiento básica debe encontrar por qué su código no lo está haciendo tan bien como debería. Es tentador hacerlo inspeccionando: simplemente mirar el código y tratar de encontrar algo que parece que necesita una mejora. Estará perdiendo el tiempo, Usar un perfilador para obtener una lista detallada de lo que su programa está haciendo es, realmente, la única forma de estar seguro.

note: (itstool) path: section/p
en: 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.
es_ES: Generalmente el problema está aislado en pequeñas partes del código. Elija la peor parte y concéntrese en ella primero. Una vez que lo haya hecho, vuelva al perfilador y repita el proceso. Según proceda, las mejoras obtenidas en cada paso se harán cada vez más pequeñas, en algún punto tendrá que decidir que los resultados son suficientes. Si sus esfuerzos sólo están obteniendo un 10% de mejoras entonces hace tiempo que pasó el punto en el que debería haber parado.

note: (itstool) path: section/p
en: 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.
es_ES: No se olvide del objetivo final. Por ejemplo, en lugar de intentar mejorar un trozo de código, pregúntese si realmente se necesita ejecutar ese código. ¿Se podría combinar con otro trozo de código? ¿Se pueden guardar y reusar cálculos previos? No necesitará optimizarse si está en un lugar donde el usuario no lo va a notar. O aún peor, el código puede ya estar optimizado y está haciendo cálculos pesados ahora para evitar hacerlos luego. El código no se ejecuta aisladamente ni tampoco lo hace el proceso de optimización.

note: (itstool) path: section/title
en: Hints
es_ES: Sugerencias

note: (itstool) path: item/title
en: The Fundamentals
es_ES: Lo fundamental

note: (itstool) path: item/p
en: 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.
es_ES: Vuelva a ejecutar su prueba de rendimiento después de cada cambio que realice sobre el código y mantenga un registro de todo lo que cambia y de cómo afecta al rendimiento. Esto le permite deshacer errores y también le ayuda a no repetirlos.

note: (itstool) path: item/p
en: Make sure your code is correct and bug-free before optimizing it. Check that it remains correct and bug-free after optimization.
es_ES: Asegúrese de que su código es correcto y está libre de errores antes de optimizarlo. Compruebe que permanece correcto y libre de errores después de haberlo optimizado.

note: (itstool) path: item/p
en: Optimize at the high level before optimizing the details.
es_ES: Optimizar al nivel más alto antes de optimizar los detalles.

note: (itstool) path: item/p
en: 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.
es_ES: Usar el algoritmo correcto. El clásico ejemplo de libro de texto es usar ordenación rápida en lugar de ordenación de burbuja. Existen muchos otros, algunos ahorran memoria, algunos ahorran CPU. También debe ver qué atajos de teclado puede crear: puede hacerlo más rápido que una ordenación rápida si está preparado para tomar ciertos compromisos.

note: (itstool) path: item/p
en: 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.
es_ES: La optimización es intercambio. Obtener resultados mejora los cálculos pero aumenta la memoria en uso. Guardar datos al disco ahorra memoria pero cuesta tiempo al cargarlos de nuevo desde el disco.

note: (itstool) path: item/p
en: 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.
es_ES: Asegúrese de elegir cierta variedad de entradas que optimizar. Si no lo hace es fácil que termine con un trozo de código cuidadosamente optimizado para un campo y no para otros.

note: (itstool) path: item/p
en: 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.
es_ES: Evite las operaciones caras: múltiples lecturas de disco pequeñas. Use un montón de memoria para que el área de intercambio («swap») se haga innecesario. Evite cualquier cosa que escriba o lea innecesariamente del disco. La red también es lenta. Evite también operaciones gráficas que necesitan una respuesta del servidor X.

note: (itstool) path: item/title
en: Traps for the Unwary
es_ES: Trampas para los imprudentes

note: (itstool) path: item/p
en: 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.
es_ES: Esté atento a efectos laterales. Generalmente son interacciones extrañas entre diferentes secciones del código, una extensión de una parte puede retardar otra.

note: (itstool) path: item/p
en: 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.
es_ES: Al cronometrar el tiempo del código, incluso en un sistema silencioso, los eventos fuera del programa añaden ruido a los resultados del tiempo. Haga la media sobre múltiples ejecuciones. Si el código es muy pequeño la resolución del tiempo también es un problema. En este caso mida el tiempo que el equipo tarda en ejecutar el código 100 o 1000 veces. Si los tiempos que está obteniendo son algo superiores a unos pocos segundos todo debería estar correcto.

note: (itstool) path: item/p
en: 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.
es_ES: Es muy fácil perderse con el perfilador. Existen historias de programadores optimizando el bucle de inactividad porque es donde se perdía todo su tiempo. No optimice código del que el usuario no se preocupe.

note: (itstool) path: item/p
en: 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.
es_ES: Recuerde los resultados del servidor X. El uso de memoria de su programa no incluye los pixmaps almacenados en los procesos del servidor X, pero aún siguen usando memoria. Use xrestop para ver los recursos que está usando su programa.

note: (itstool) path: item/title
en: Low Level Hints
es_ES: Consejos de bajo nivel

note: (itstool) path: item/p
en: 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.
es_ES: Al optimizar el uso de memoria considere la diferencia entre el uso de pico y el uso medio de memoria. Alguna memoria siempre está reservada, esto generalmente es malo. Alguna está temporalmente reservada, esto puede ser aceptable. Herramientas como massif usan el concepto de espacio-tiempo, el producto de la memoria usada y el tiempo durante el que estuvo reservada.

note: (itstool) path: item/p
en: 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.
es_ES: Controle el tiempo de trozos de código simplificados que sólo hacen cosas esenciales, esto proporciona un límite absoluto inferior en el tiempo que usará el código. Por ejemplo, al optimizar un bucle, controle el tiempo del bucle vacío. Si aún es mucho tiempo cualquier intento de optimización no ayudará y deberá cambiar su diseño. Asegúrese de que el compilador no desoptimiza el bucle vacío.

note: (itstool) path: item/p
en: 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.
es_ES: Mueva el código fuera de los bucles internos. Un trozo de código más complicado que se ejecuta una sola vez es mucho más rápido que un trozo de código más simple que se ejecuta mil veces. Evite llamar habitualmente a código lento.

note: (itstool) path: item/p
en: Give the compiler as many hints as possible. Use the const keyword. Use <code>G_INLINE_FUNC</code> for short, frequently called, functions. Look up <code>G_GNUC_PURE</code>, <code>G_LIKELY</code> and the other glib miscellaneous macros. Use the macros instead of gcc-specific keywords to ensure portability.
es_ES: Proporcione al compilador tantos sugerencias como le sea posible. Use la palabra clave «const». Use <code>G_INLINE_FUNC</code> para funciones cortas frecuentemente llamadas. Busque <code>G_GNUC_PURE</code>, <code>G_LIKELY</code> y otras macros misceláneas de glib. Use las macros en lugar de palabras clave específicas de gcc para asegurar la portabilidad.

note: (itstool) path: item/p
en: 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).
es_ES: No use lenguajes de ensamblado. El código no es portable y puede ser más rápido en un procesador que en otro, además no está garantizado que sea rápido en cada procesador que soporta esa arquitectura (ej. Athlon contra Pentium 4).

note: (itstool) path: item/p
en: 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.
es_ES: No reescriba una rutina existente de una biblioteca a no ser que esté seguro de que es demasiado lenta. Muchas rutinas de bibliotecas de uso intensivo por la CPU ya se han optimizado. Algunas rutinas de bibliotecas son lentas, especialmente aquellas que realizan llamadas al sistema operativo.

note: (itstool) path: item/p
en: 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.
es_ES: Minimice el número de bibliotecas a las que enlaza. Cuanto menor sea el número de bibliotecas que enlazar, más rápido se iniciará el programa. Es una tarea difícil en GNOME.

note: (itstool) path: item/title
en: High Level Tricks
es_ES: Trucos de alto nivel

note: (itstool) path: item/p
en: 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.
es_ES: La ventaja de la concurrencia. Esto no significa simplemente usar varios procesadores, también significa aprovecharse del tiempo que el usuario pasa pensando en qué harán después, para realizar algunos cálculos anticipados. Haga cálculos mientras se espera la carga de datos desde el disco. Aprovéchese de los recursos múltiples, úselos todos a la vez.

note: (itstool) path: item/p
en: 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.
es_ES: Engañe. El usuario sólo tiene que pensar que el equipo es rápido, no importa si realmente lo es o no. Es el tiempo entre el comando y la respuesta es lo que importa, no importa si la respuesta estaba precalculada, cacheada o se trabajará en ella en cualquier momento posterior conveniente, siempre que el usuario obtenga lo que espera.

note: (itstool) path: item/p
en: 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.
es_ES: Realice trabajo en el bucle de inactividad. Es más fácil de programar que usar programación completa para multihilo pero aún así las cosas se hacen fuera de la vista del usuario. No obstante, sea cuidadoso, si se queda demasiado tiempo en el bucle de inactividad su programa acabará siendo lento. Por eso debe devolver regularmente el control al bucle principal.

note: (itstool) path: item/p
en: 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.
es_ES: Si todo lo demás falla, dígale al usuario que el código va a ser lento y ponga una barra de progreso. No estarán tan contentos como si hubiese mostrado el resultado pero al menos sabrán que el programa no se ha colgado y que se pueden ir a preparar un café.

note: (itstool) path: page/title
en: Using <app>Massif</app> for Profiling Memory Use in GNOME Software
es_ES: Usar <app>Massif</app> para el Perfilado del uso de memoria en software de GNOME

note: (itstool) path: section/p
en: <app>Massif</app> is a member of the <link href="http://valgrind.org/">valgrind</link> 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.
es_ES: <app>Massif</app> es un miembro de las herramientas de perfilado de memoria <link href="http://valgrind.org/">valgrind</link>. Su propósito es proporcionar una vista detallada del uso de memoria dinámica durante la vida de un programa. Específicamente graba el uso de memoria del montículo («heap») y de la pila.

note: (itstool) path: section/p
en: 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 <app>Massif</app> treats it as though it were just another part of the heap. <app>Massif</app> also gives information about how much memory is used to manage the heap.
es_ES: El montículo («heap») es la región de memoria que está reservada con funciones como «malloc». Crece bajo demanda y generalmente es la región de memoria más grande del programa. La pila es donde se almacenan todos los datos locales para las funciones. Incluye las variables «automáticas» de C y las direcciones de vuelta para las subrutinas. Generalmente la pila es mucho más pequeña y activa que el montículo. No se considerará explícitamente la pila ya que <app>Massif</app> la trata como si fuese otra parte del montículo. <app>Massif</app> también proporciona información acerca de cuánta memoria se usa para gestionar el montículo.

note: (itstool) path: section/p
en: <app>Massif</app> produces two output files: a graphical overview in a postscript file and a detailed breakdown in a text file.
es_ES: <app>Massif</app> produce dos archivos de salida: una vista general gráfica en un archivo postscript y un archivo de texto detallado.

note: (itstool) path: section/title
en: Using <app>Massif</app> with GNOME
es_ES: Usar <app>Massif</app> con GNOME

note: (itstool) path: section/p
en: <app>Massif</app> 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.
es_ES: <app>Massif</app> tiene muy pocas opciones y para la mayoría de programas no se necesitan. No obstante, para las aplicaciones de GNOME donde la reserva de memoria puede estar debajo de glib o GTK, se debe aumentar el número de niveles debajo de la pilla de llamadas al que tiene descender Massif. Se consigue usando el parámetro «--depth». De forma predeterminada es 3; aumentarlo a 5 garantizará que la pilla de llamadas llega a su zona de código. Uno o dos niveles más pueden ser deseables para proporcionar algo de contexto al código. Ya que el nivel de detalle se convierte en insoportable, es mejor comenzar con un parámetro de profundidad pequeño e ir aumentándolo cuando parezca que es insuficiente.

note: (itstool) path: section/p
en: It is also useful to tell <app>Massif</app> 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 Massif about them.
es_ES: También es útil decir a <app>Massif</app> qué funciones reservan memoria en glib. Quita una capa de llamadas de funciones innecesarias de los informes y le proporciona una idea más clara de qué código está reservando memoria. Las funciones de reserva de memoria en glib son «g_malloc», «g_malloc0», «g_realloc», «g_try_malloc», y «g_mem_chunk_alloc». Use la opción «--alloc-fn» para pasarle la opción a Massif.

note: (itstool) path: section/p
en: Your command-line should therefore look something like:
es_ES: Su línea de comando debería parecerse a esta:

note: (itstool) path: section/p
en: <app>Swell Foop</app> is the program we will be using as an example. Be warned that, since valgrind emulates the CPU, it will run <em>very</em> slowly. You will also need a lot of memory.
es_ES: <app>Swell Foop</app> es el programa que se usará como ejemplo. Tenga en cuenta que, ya que valgrind emula la CPU, se ejecutará <em>muy</em> despacio. También necesitará mucha memoria.

note: (itstool) path: section/title
en: Interpreting the Results
es_ES: Interpretar los resultados

note: (itstool) path: section/p
en: The graphical output of <app>Massif</app> 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.
es_ES: La salida gráfica de <app>Massif</app> se explica por si misma. Cada banda representa la memoria que una función tiene reservada en el tiempo. Una vez que haya identificado las bandas que usan más memoria, generalmente las anchas en la parte superior, tendrá que consultar el archivo de texto para ver los detalles.

note: (itstool) path: section/p
en: 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.
es_ES: El archivo de texto se organiza como una jerarquía de secciones, en la parte superior hay una lista de los peores usuarios de memoria organizada en orden decreciente. Debajo de esta lista están las siguientes secciones, cada una mostrando los resultados en detalle según se procede en la pila de llamadas. Para ilustrar esto se usará la salida del comando anterior.

note: (itstool) path: figure/title
en: <app>Massif</app> output for the unoptimized version of the <app>Swell Foop</app> program.
es_ES: La salida de <app>Massif</app> para la versión no optimizada del programa <app>Swell Foop</app>.

note: (itstool) path: section/p
en: The image above shows a typical postscript output from <app>Massif</app>. This is the result you would get from playing a single game of <app>Swell Foop</app> (version 2.8.0) and then quitting. The postscript file will have a name like <file>massif.12345.ps</file> and the text file will be called <file>massif.12345.txt</file>. 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 <app>Swell Foop</app> starts a second process and <app>Massif</app> follows that too. We will ignore this second process, it consumes very little memory.
es_ES: La imagen anterior muestra una salida postscript típica de <app>Massif</app>. Este es el resultado que obtendrá al jugar una partida simple de <app>Swell Foop</app> (versión 2.8.0) y después salir. El archivo postscript tendrá un nombre tipo <file>massif.12345.ps</file> y el archivo de texto se llamará <file>massif.12345.txt</file>. El número en el medio es el ID del proceso del programa que se examinó. Si prueba este ejemplo encontrará dos versiones de cada archivo con números ligeramente diferentes, esto es porque <app>Swell Foop</app> inicia un segundo proceso y <app>Massif</app> también lo sigue. Se ignorará el segundo proceso ya que consume muy poca memoria.

note: (itstool) path: section/p
en: 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:
es_ES: En la parte superior de la gráfica se ve una gran banda amarilla etiquetada como gdk_pixbuf_new. Parece ser un candidato ideal para la optimización, pero se necesitará usar el archivo de texto para encontrar qué está llamando a gdk_pixbuf_new. La parte superior del archivo de texto mostrará algo como lo siguiente:

note: (itstool) path: section/p
en: 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:
es_ES: La línea con los signos «=» indica a qué distancia de la traza de la pila estamos, en este caso al principio. Después lista los mayores usuarios de memoria en orden decreciente del espacio-tiempo. El espacio-tiempo es el producto de la cantidad de memoria usada y de la duración de su uso. Se corresponde con el área de las bandas en el gráfico. Esta parte del archivo proporciona información acerca de algo que ya se sabe: la mayoría del espacio-tiempo se dedica a gdk_pixbuf_new. Para buscar qué llamó a gdk_pixbuf_new necesitamos buscar más abajo en el archivo de texto:

note: (itstool) path: section/p
en: 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 <app>Swell Foop</app> code. From this listing, we can see instantly that the problem code is load_scenario.
es_ES: La primera línea dice que estamos a cuatro niveles de profundidad en la pila. Debajo es una lista de las llamadas de funciones que de aquí a gdk_pixbuf_new. Finalmente existe una lista de funciones que son el siguiente nivel por debajo y llaman a esas funciones. También existen, obviamente, entradas para los niveles 1, 2 y 3, pero este es el primer nivel que llega justo debajo del código GDK del código de <app>Swell Foop</app>. Desde esta lista se puede ver instantáneamente que el problema del código es «load_scenario».

note: (itstool) path: section/p
en: 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.
es_ES: Ahora que se sabe qué parte del código usa todo el espacio de tiempo se puede buscar el porqué. Resulta que load_scenario está cargando un pixbuf de un archivo y nunca libera esa memoria. Habiendo identificado el código del problema se puede comenzar a arreglarlo.

note: (itstool) path: section/title
en: Acting on the Results
es_ES: Actuar sobre los resultados

note: (itstool) path: section/p
en: 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.
es_ES: Reducir el consumo de espacio-tiempo es bueno, pero existen otras dos formas de reducirlo y no son iguales. Puede reducir la cantidad de memoria reservada o reducir la cantidad de tiempo que está reservada. Considere por un momento un modelo de sistema con sólo dos procesadores. Ambos procesadores usan toda la memoria RAM física y si se solapan el sistema usará la memoria de intercambio y todo se ralentizará. Obviamente si se reduce el uso de memoria de cada proceso en un factor de dos, entonces pueden coexistir pacíficamente sin necesidad de usar la memoria de intercambio. Si en lugar de ello se reduce el tiempo que la memoria está reservada en un factor de dos, entonces los dos programas pueden coexistir, pero sólo siempre que sus periodos de máximo uso de memoria no se solapen. Por ello es mejor reducir la cantidad de memoria reservada.

note: (itstool) path: section/p
en: Unfortunately, the choice of optimization is also constrained by the needs of the program. The size of the pixbuf data in <app>Swell Foop</app> 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. The image below shows the <app>Massif</app> analysis of <app>Swell Foop</app> after being altered to dispose of the pixbufs once the images have been loaded into the X server.
es_ES: Desafortunadamente la opción de la optimización también está restringida por las necesidades del programa. El tamaño de los datos de pixbuf en <app>Swell Foop</app> está determinado por el tamaño de los gráficos del juego y no se puede reducir fácilmente. No obstante, la cantidad de tiempo que está cargado en la memoria se puede reducir drásticamente. La siguiente imagen muestra el análisis de <app>Massif</app> para <app>Swell Foop</app> después de alterar la disposición de los pixbuf una vez que se han cargado las imágenes en el servidor X.

note: (itstool) path: figure/title
en: <app>Massif</app> output for the optimized <app>Swell Foop</app> program.
es_ES: La salida de <app>Massif</app> para el programa optimizado <app>Swell Foop</app>.

note: (itstool) path: section/p
en: 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 were run together the chances of the peak memory usage coinciding, and hence the risk of swapping, would be quite low.
es_ES: Ahora el espacio-tiempo que usa gdk_pixbuf_new es una banda delgada que sólo tiene picos brevemente (ahora es la banda número dieciséis de magenta sombreado). Como ventaja, el pico de memoria ha disminuido 200 kB ya que el pico ocurre antes de que se reserve otra memoria. Si dos procesos como estos se tuviesen que ejecutar a la vez las posibilidades de que los picos de uso de memoria coincidiesen, y por ello el riesgo de usar la memoria de intercambio, serían bastante escasas.

note: (itstool) path: section/p
en: Can we do better ? A quick examination of <app>Massif</app>'s text output reveals: g_strdup to be the new major offender.
es_ES: ¿Se puede hacer mejor? Un examen rápido de la salida de texto de <app>Massif</app> releva que g_strdup es el nuevo mayor problema.

note: (itstool) path: section/p
en: If we look closer though we see that it is called from many, many, places.
es_ES: Si se mira con detenimiento se ve que se llama desde muchos, muchos sitios.

note: (itstool) path: section/p
en: 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 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.
es_ES: Ahora se encara la reducción de la salida para los esfuerzos de optimización. El gráfico sugiere otra posible aproximación: tanto la banda «other» como la «heap admin» son bastante largas. Esto quiere decir que existen muchas pequeñas reservas realizadas desde cierta variedad de sitios. Eliminarlas será difícil, pero si se pueden agrupar, entonces las reservas individuales pueden ser más grandes y la elevada banda «heap admin» puede reducirse.

note: (itstool) path: section/title
en: Caveats
es_ES: Advertencias

note: (itstool) path: section/p
en: 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.
es_ES: Existen un par de cosas cosas para tener en cuenta: Primeramente, sólo se informa del espacio de tiempo como porcentaje, tiene que compararlo con el tamaño total del programa para decidir si merece la pena perseguir la cantidad total de memoria. El gráfico, con su eje vertical de kilobytes, es bueno para ello.

note: (itstool) path: section/p
en: Secondly, <app>Massif</app> 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 <app>Massif</app>. In the <app>Swell Foop</app> 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 <link href="http://www.freedesktop.org/Software/xrestop">xrestop</link> program.
es_ES: Segundo, <app>Massif</app> sólo tiene en cuenta la memoria usada por su propio programa. Los recursos como los mapas de píxeles se almacenan en el servidor X y <app>Massif</app> no los considera. En el ejemplo de <app>Swell Foop</app> realmente sólo se ha movido el consumo de memoria de los pixbuf de la parte del cliente a los pixbuf de la parte del servidor. Aunque se haya hecho trampa se ha ganado en rendimiento. Mantener los datos de imágenes en el servidor X hace que las rutinas de gráficos sean más rápidas y elimina muchos procesos de comunicación interna. También, los mapas de píxeles se almacenan en un formato de gráficos nativo que es más compacto que el formato de 32-bit RGBA usado por gdk_pixbuf. Para medir el efecto de los mapas de píxeles y otros recursos X use el programa <link href="http://www.freedesktop.org/Software/xrestop">xrestop</link>.
