gnome-devel-docs master - en to gl translation catalogue (65 entries)

note: (itstool) path: page/title
en: Disk Seeks Considered Harmful
gl: Buscas 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:
gl: As buscas de disco son unha das operacións máis caras que pode realizar. Pode que non saiba isto simplemente mirando cantas se realizan, pero crea que realmente o son. Por iso, evite os seguintes comportamentos:

note: (itstool) path: item/p
en: Placing lots of small files all over the disk.
gl: Localizar montóns de pequenos ficheiros por todo o disco.

note: (itstool) path: item/p
en: Opening, stating, and reading lots of files all over the disk
gl: Abrir, iniciar e ler montóns de ficheiros por todo o 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.
gl: Realizar o anterior sobre ficheiros que se abren en diferentes momentos, para asegurarse de que están fragmentados e causan aínda máis buscas no disco.

note: (itstool) path: item/p
en: Repeatedly doing the above when it only needs to be done once.
gl: Realizar de forma repetida o anterior cando só se precisa realizar unha vez.

note: (itstool) path: page/p
en: Ways in which you can optimize your code to be seek-friendly:
gl: Formas nas que pode optimizar o seu código para que sexa amigábel á hora de facer buscas:

note: (itstool) path: item/p
en: Consolidate data into a single file.
gl: Consolidar os datos nun só ficheiro.

note: (itstool) path: item/p
en: Keep data together in the same directory.
gl: Manter os datos xuntos no mesmo cartafol.

note: (itstool) path: item/p
en: Cache data so as to not need to reread constantly.
gl: Cachear os datos para non ter que volver a lelos constantemente.

note: (itstool) path: item/p
en: Share data so as not to have to reread it from disk when each application loads.
gl: Compartir os datos para non ter que volver a lelos do disco cada vez que unha aplicación se carga.

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.
gl: O problema coas buscas nos discos complícase para as lecturas, que é desafortunadamente o que se busca. Lembre, as lecturas son xeralmente síncronas mentres que as escrituras son asíncronas. Isto só complica o problema, serializando cada lectura e contribuíndo á latencia do programa.

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.
gl: Moitos dos nomes usados por empresas para distinguir os seus produtos e servizos son marcas rexistradas. Cando aparezan ditos nomes na documentación de GNOME, e esas marcas rexistradas se lle mostren aos membros do Proxecto de Documentación de GNOME, os nomes son escritos en maiúsculas ou maiúscula inicial.

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.
gl: O software pode optimizarse de moitas formas: para maior velocidade, tamaño do programa ou uso de memoria. Esta sección contén guías e titoriais para optimizar o seu software.

note: (itstool) path: section/title
en: Introduction
gl: Introdució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.
gl: Esta é unha breve introdución á optimización, dos cómos tanto dos porqués. Déixanse para posteriores artigos os detalles de ferramentas e técnicas individuais pero fornécese unha colección de suxestións e 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.
gl: Este artigo describe como usar o perfilador de pila <application>Massif</application> con aplicacións de GNOME. Describirémoslle como invocalo, interpretar e actual sobre a saída de <application>Massif</application>. Usaremos o xogo <application>Swell Foop</application> para este exemplo.

note: (itstool) path: page/title
en: What are we Optimizing?
gl: Que 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.
gl: Ao optimizar GNOME o primeiro que hai que lembrar é isto: non se está tentando mellorar o programa, estase tentando mellorando facer que as persoas usen o equipo máis 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.
gl: Programas mellores fan á xente máis feliz pero existen algunhas mellores que faranos máis felices que outras: tempo de resposta, tempo de inicio, facilidade para acceder a ordes e que o equipo non teña que usar a memoria de intercambio cando máis de dous programas estean abertos.

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.
gl: A optimización tradicional contempla conceptos como o uso de CPI, o tamaño do código, o número de pulsacións do reato e o uso de memoria de programa. Elixiuse esta segunda lista para correlar como a primeira, porén existe unha diferenza importante. Á persoa que usa GNOME non lle importa a segunda lista, pero sí a primeira. Ao optimizar os programas de GNOME reducirase o uso de CPU, o uso de memoria e todo aquelo, pero son conceptos para o fin, non o obxectivo final. Optimízase para as persoas.

note: (itstool) path: section/title
en: Doing the Optimization
gl: Realizar a 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.
gl: Na sección anterior omitiuse un calificador importante: optimizar algo debe ser medíbel. Non se pode medir a felicidade. Porén pódese medir o tempo de inicio dun programa para saber se se mellorou. A felicidade do usuario aumentará pois.

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.
gl: Unha vez que ten unha proba de rendemento básica debe atopar por que o seu código non o está facendo tan ben como debería. É tentado facelo inspeccionando: simplemente mirar o código e tratar de atopar algo que parece que precisa unha mellora. Estará perdendo o tempo, usar un perfilador para obter unha lista detallada do que o seu programa está facendo é, realmente, a ú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.
gl: Xeralmente o problema está illado en pequenas partes do código. Elixa a peor parte e concéntrese nesa primeiro. Unha vez que o teña feito, volva ao perfilador e repita o proceso. Segundo proceda, as melloras obtidas en cada paso faranse cada vez máis pequenas, nalgún punto terá que decidir que os resultados son suficientes. Se os seus esforzos só están obtendo un 10% de melloras entón fai tempo que pasou o punto en que debería ter 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.
gl: Non esqueza a visión xeral. Por exemplo, fronte a só tentar incrementar o rendemento dunha parte do código, pregúntese se realmente se precisa dita parte. Pode ser fornecida por outra parte do seu código? Poden os resultados de cálculos previos gardados e ser reusados? Podería non ser nin preciso optimizalo se é un lugar onde nunca vai ir o usuario para que poida notalo. Ou peor aínda, que o código xa estea optimizado e está facendo un cálculo moi grande agora para evitar facelo máis tarde. O código non se executa en separación e tampouco o fai nun proceso de optimizado.

note: (itstool) path: section/title
en: Hints
gl: Suxestións

note: (itstool) path: item/title
en: The Fundamentals
gl: O 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.
gl: Volva a executar a súa proba de rendemento despois de cada cambio que realice sobre o código e manteña un rexistro de todo o que cambia e de como afecta ao rendemento. Isto permítelle desfacer erros e tamén axúdalle a non repetilos.

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.
gl: Asegúrse de que o seu código é correcto e está libre de erros antes de optimizalo. Comprobe que permanece correcto e libre de erros desois de telo optimizado.

note: (itstool) path: item/p
en: Optimize at the high level before optimizing the details.
gl: Optimizar ao nivel máis alto antes de optimizar os 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.
gl: Use o algoritmo correcto. O clásico exemplo de libro de texto é usar ordenación rápida no lugar de ordenación por burbulla. Existen moitos outros, algúns aforran memoria, alguns aforran CPU. Tamén debe ver que atallos de teclado pode crear: pode facelo máis rápido que unha ordenación rápida se está preparado para tomar certos 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.
gl: A optimización é intercambio. Obter resultados mellora os cálculos pero aumenta a memoria en uso. Gardar datos ao disco aforra memoria pero custa tempo ao cargalos de novo desde o 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.
gl: Asegúrese de elixir certa variedade de entradas que optimizar. SE non o fai é doado que remate cun trozo de código coidadosamente optimizado par aun campo e non para outros.

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.
gl: Evite as operacións caras: múltiples lecturas de disco pequenas. Use un montón de memoria para que a área de intercambio («swap») fágase innecesario. Evite calquera cousa que escriba ou lea innecesariamente do disco. A rede tamén é lenta. Evite tamén operacións gráficas que precisan unha resposta do servidor X.

note: (itstool) path: item/title
en: Traps for the Unwary
gl: Trampas para os 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.
gl: Estea atento aos efectos colaterais. Xeralmente son interaccións estranas entre diferentes seccións do código, unha extensión dunha parte pode retardar outra.

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.
gl: Ao cronometrar o tempo do código, incluso nun sistema parado, os eventos fora do programa engaden ruido aos resultados de tempo. Faga unha medida sobre múltiples execucións. Se o código é moi pequeno a resolución do tempo tamén é un problema. Neste caso mida o tempo que o equipo tarda en executar o código 100 ou 1000 veces. Se os tempos que está obtendo son algo superiores a uns poucos 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.
gl: É moi doado perferse co perfilador. Existen historias de programadores optimizando o búcle de inactividade porque é onde se perdía todo o seu tempo. Non optimice código do que o usuario non 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.
gl: Lembre os resultados do servidor X. O uso de memoria do seu programa non inclúe os pixmaps almacenados nos procesos do servidor X, pero aínda seguen usando memoria. Use xrestop para ver os recursos que está usando o seu programa.

note: (itstool) path: item/title
en: Low Level Hints
gl: Consellos de baixo 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.
gl: Ao optimizar o uso de memoria considere a diferenza entre o uso de pico e o uso medio de memoria. Algunha memoria sempre está reservada, isto xeralmente é malo. Algunha está temporalmente reservada, isto pode ser aceptábel. Ferramentas como massif usan o concepto de espazo-tempo, o produto da memoria usada e o tempo durante o que estivo 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.
gl: Controle o tempo de trozos de código simplificados que só fan cousas esenciais, isto fornece un límite absoluto inferior no tempo que usará o código. Por exemplo, ao optimizar un búcle, controle o tempo do búcle baleiro. Se aínda é moito tempo calquera intento de optimización non axudará e deberá cambiar o seu deseño. Asegúrese de que o compilador non desoptimiza o búcle baleiro.

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.
gl: Mova o código fóra dos bucles internos. Un anaco de código máis complicado que se executa unha soa vez é moito máis rápido que un anaco de código máis sinxelo que se executa mil veces. Evite chamar habitualmente a código lento.

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).
gl: Non use linguaxes de ensamblado. O código non é portábel e pode ser máis rápido nun procesador que noutro, ademais non está garantizado que sea rápido en cada procesador que admite esa arquitectura (p.ex. 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.
gl: Non rescriba unha rutina existente dunha biblioteca a non ser que estea seguro de que é demasiado lenta. Moitas rutinas de bibliotecas de uso intensivo pola CPU xa se optimizaron. Algunhas rutinas de bibliotecas son lentas, especialmente aquelas que realizan chamadas ao 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.
gl: Minimice o número de bibliotecas ás que liga. Canto menor sexa o número de bibliotecas a ligar, máis rápido se iniciará o programa. É unha tarefa difícil en GNOME.

note: (itstool) path: item/title
en: High Level Tricks
gl: 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.
gl: A ventaxa da concurrencia. Isto non significa simplemente usar varios procesadores, tamén significa aproveitarse do tempo que o usuario pasa pensando en que fará despois, para realizar algúns cálculos anticipados. Faga cálculos mentres se agarda a carga de datos desde o disco. Aprovéitese dos recursos múltiples, úseos todos á 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.
gl: Engane. O usuario só ten que pensar que o equipo é rápido, non importa se realmente o é ou non. É o tempo entre a orde e a resposta o que importa, non importa se a resposta esta precalculada, cacheada ou se traballará nela en calquera momento posterior conveniente, sempre que o usuario obteña o que agarda.

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.
gl: Facer cousas no búcle ocioso. É máis doado programar usando multifíos e facer cousas por detrás dos ollos do usuario. Teña coidado, se pasa gasta moito tempo no bucle ocioso o seu programa podería volverse lento. Polo que de forma regular déalle de novo o control ao 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.
gl: Se todo isto falla, dígalle ao usuario que o código vai a executarse vai ser lento e móstrelle unha barra de progreso. Non estará tan contento con isto como se simplemente lle mostrara os resultados, porén cando menos saberá que o programa non se pechou ou ten problemas e pode ir a tomarse un café mentres.

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.
gl: <application>Massif</application> ten varias opcións e algúns programas non as precisan. Porén para as aplicacións GNOME, a medida que baixa nos niveles da pila de chamadas os descendentes de Massif deben incrementarse. Isto pódese facer empregando o parámetro --depth. Por omisión isto é 3; incrementándoa a 5 garantizaralle que a pila de chamadas alcanza o seu código. Un ou máis niveles poden ser desexabeis para fornecerlle algún contexto ao seu código. Xa que o nivel de detalles pode ser moi rapidamente inxestionábel é mellor comezar con un valor de profundidade menos profundo e só incrementalo cando aparentemente non sexa dabondo.

note: (itstool) path: section/p
en: Your command-line should therefore look something like:
gl: A súa liña de orde debería semellarse a esta:

note: (itstool) path: section/title
en: Interpreting the Results
gl: Interpretar os resultados

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.
gl: O ficheiro de texto está ordenado como unha xerarquía por seccións, na parte superior está unha lista dos peores usuarios da memoria para reducir o espazotempo. Máis abaixo de isto están as seguintes sección, cada unha delas dividindo os resultados en maior detalle como se procedera cara abaixo na pila de chamadas. Para ilustrar isto usaremos a saída da orde de arriba.

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:
gl: Na parte superior da gráfica vese unha gran banda amarela etiquetada como gdk_pixbuf_new. Semella un candidato ideal para a optimización, pero precisarase usar o ficheiro de texto para topar que está chamando a gdk_pixbuf_new. A parte superior do ficheiro de texto mostrará algo como o seguinte:

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.
gl: Agora que sabe que parte do código usa todo o espazo de tempo pódese buscar o porque. Resulta que load_scenario está cargando un pixbuf dun ficheiro e nunca libera esa memoria. Tendo identificado o código do problema pódese comezar a arranxalo.

note: (itstool) path: section/title
en: Acting on the Results
gl: Actuar sobre os 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.
gl: Reducir o consumo do espazo de tempo é bo, pero hai dúas formas de reducilo e non son iguais. Pode tanto reducir a cantidade de memoria reservada como reducir a cantidade de tempo na que está reservada. Considere por un momento un sistema modelo con só dous procesos executándose. Ámbolos dous procesos usan case toda a RAM física e superpóñense por completo polo que o sistema terá que usar a swap e todo se ralentizará. Se no lugar disto reducimos o tempo que está reservada a memoria por un factor de dous entón os dous programas poden coexistir, pero mentres os seus períodos de alto uso de memoria non se superpoñan. Polo tanto é mellor reducir o consumo de memoria reservada.

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.
gl: O uso do espazo de tempo do gdk_pixbuf_new é agora unha banda máis estreita que só ten picos moi brebes (agora é a dezaseisava banda e pintada en maxenta). Ademáis, o pico de uso de memoria baixou 200 kB xa que o pico se produce antes de que se reserve outra memoria. Se dous procesos como este estiveran executándose á vez as opcións dun pico de uso de memoria coincidente, e polo tanto o risco de facer swapping, serán moi poucas.

note: (itstool) path: section/p
en: If we look closer though we see that it is called from many, many, places.
gl: Se miramos máis cerca nas partes que vemos se chaman desde moitas partes.

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.
gl: Agora encárase a redución da saída para os esforzos de optimización. O gráfico suxire outra posíbel aproximación: tanto a banda «other» como a «heap admin» son bastante largas. Isto quere dicir que existen moitas pequenas reservas realizadas desde certa variedade de sitios. Eliminalos será difícil, pero se se poden agrupar, entón as reservas son individuais poden ser máis grandes e a elevada banda «heap admin» pode reducirse.

note: (itstool) path: section/title
en: Caveats
gl: 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.
gl: Existen un par de cousas para ter en conta: Primeiramente, só se informa do espazo de tempo como porcentaxe, ten que comparalo co tamaño total do programa para decidir se merece a pena perseguir a cantidade total de memoria. O gráfico, co seu eixe vertical de kilobytes, é bo para iso.
