gnome-devel-docs master - en to pt_BR translation catalogue (92 entries)

note: (itstool) path: page/title
en: Disk Seeks Considered Harmful
pt_BR: Buscas em disco são consideradas prejudiciais

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:
pt_BR: Buscas em disco são uma das operações mais custosas que você possivelmente pode realizar. Você pode não saber isto apenas olhando quantas delas realizamos porém, acredite em mim, elas são. Deste modo, por favor abstenha-se deste comportamento abaixo do normal que se segue:

note: (itstool) path: item/p
en: Placing lots of small files all over the disk.
pt_BR: Colocando vários pequenos arquivos sobre todo o disco.

note: (itstool) path: item/p
en: Opening, stating, and reading lots of files all over the disk
pt_BR: Abrindo, iniciando, e lendo vários arquivos sobre 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.
pt_BR: Fazer o que está acima em arquivos que são dispostos em tempos diferentes, garante que os arquivos são fragmentados e causem ainda mais buscas em 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.
pt_BR: Fazer o que está acima em arquivos que estão em diferentes diretórios, garante que os arquivos estão em diferentes grupos de cilindros e causem ainda mais buscas em disco.

note: (itstool) path: item/p
en: Repeatedly doing the above when it only needs to be done once.
pt_BR: Faça repetidamente o que está acima apenas quando for necessário fazer uma única vez.

note: (itstool) path: page/p
en: Ways in which you can optimize your code to be seek-friendly:
pt_BR: Modos pelos quais você pode otimizar seu código para realizar pesquisas de forma amigável:

note: (itstool) path: item/p
en: Consolidate data into a single file.
pt_BR: Consolidar os dados em um único arquivo.

note: (itstool) path: item/p
en: Keep data together in the same directory.
pt_BR: Manter os dados juntos no mesmo diretório.

note: (itstool) path: item/p
en: Cache data so as to not need to reread constantly.
pt_BR: Fazer cache dos dados a fim de não precisar relê-los constantemente.

note: (itstool) path: item/p
en: Share data so as not to have to reread it from disk when each application loads.
pt_BR: Compartilhar os dados a fim de não precisar relê-los a partir do disco rígido quando cada aplicativo é carregado.

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.
pt_BR: Considerar fazer cache de todos os dados em um único arquivo binário, o qual está corretamente alinhado e que pode ser mapeado com mmap.

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.
pt_BR: Os problemas com pesquisas em disco são agravados pelas leituras as quais, infelizmente, são o que estamos fazendo. Lembre-se, leituras são geralmente síncronas enquanto escritas são assíncronas. Isto só agrava o problema, serializando cada leitura e contribuindo para a latência do 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.
pt_BR: Permissão concedida para copiar, distribuir e/ou modificar este documento sob os termos da Licença de Documentação Livre GNU (GNU Free Documentation License), versão 1.1 ou qualquer versão mais recente publicada pela Free Software Foundation; sem Seções Invariantes, Textos de Capa Frontal, e sem Textos de Contracapa. Você pode encontrar uma cópia da Licença de Documentação Livre GNU da Free Software Foundation visitando <link href="http://www.fsf.org">este site</link> ou escrevendo para:  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.
pt_BR: Muitos dos nomes usados por empresas para distinguir seus produtos e serviços são reivindicados como marcas registradas. Onde esses nomes aparecem em qualquer documentação do GNOME e os membros do Projeto de Documentação do GNOME estiverem cientes dessas marcas registradas, os nomes aparecerão impressos em letras maiúsculas ou com iniciais em maiú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.
pt_BR: Um software pode ser otimizado de diversas formas: na velocidade, no tamanho do programa ou na utilização de memória. Esta seção contém guias e tutoriais para otimizar seu software.

note: (itstool) path: page/title
en: Optimization Guide
pt_BR: Guia de otimização

note: (itstool) path: section/title
en: Introduction
pt_BR: Introdução

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.
pt_BR: Esta é uma breve introdução ao processo de otimização, tanto os “comos” quanto os “porquês”. Detalhes de ferramentas individuais e técnicas foram deixadas para artigos posteriores, mas uma coleção de dicas e truques são oferecidos.

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.
pt_BR: Este artigo descreve como utilizar o perfilador (profiler) de heap <app>Massif</app> com aplicativos do GNOME. Nós descrevemos como invocar, interpretar e agir sobre a saída do <app>Massif</app>. O jogo <app>Swell Foop</app> é utilizado como exemplo.

note: (itstool) path: section/title
en: Harmfulness
pt_BR: Males

note: (itstool) path: page/title
en: What are we Optimizing?
pt_BR: O que estamos otimizando?

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.
pt_BR: Quando otimizamos um software GNOME a primeira coisa que devemos lembrar é isto: não estamos tentando fazer o programa melhor, nós estamos tentando fazer a pessoa que está usando o computador mais feliz.

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.
pt_BR: Melhores programas deixam as pessoas mais felizes, entretanto há alguns aperfeiçoamentos que irão deixá-los muito mais felizes que outros: capacidade de resposta, tempo de inicialização, comandos de fácil acesso e não ter o computador entrando na memória de troca (swap) a cada momento que mais de dois programas são 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.
pt_BR: A otimização tradicional aborda conceitos como utilização de CPU, tamanho do código, o número de cliques do mouse e a utilização de memória de um programa. Esta segunda lista foi escolhida para corresponder-se com a primeira, entretanto há uma importante diferença: A pessoa que estiver utilizando o GNOME não liga para a segunda lista, mas eles se importam muito com a primeira. Quando estivermos otimizando programas GNOME nós iremos reduzir a utilização da CPU, o uso de memória e todas estas coisas, mas este é o meio para o fim, não o objetivo final. Nós estamos otimizando para pessoas.

note: (itstool) path: section/title
en: Doing the Optimization
pt_BR: Realizando a otimização

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.
pt_BR: A seção anterior omitiu um importante qualificador: para otimizar alguma coisa, esta precisa ser mensurável. Você não pode mensurar a felicidade. Contudo, você pode medir o tempo de inicialização de um programa, deste modo você pode dizer se você o melhorou. Assim espero que a felicidade, então, o siga.

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.
pt_BR: Otimização é o processo de medição, refinamento e de nova medição. Então a primeira coisa que você deve fazer é encontrar um meio de medir o que você está otimizando. O ideal é que esta medição seja um número único, por exemplo: o tempo gasto para executar uma tarefa. Esta é a sua avaliação de desempenho (benchmark), é a única forma de dizer se você está ganhando ou perdendo. Há uma grande diferença entre um programa que <em>deveria</em> ser rápido e um programa que <em>é</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.
pt_BR: Uma vez que você possua uma avaliação de desempenho básica, você precisará descobrir por que seu código não está funcionando tão bem quanto deveria. É tentador fazer isto por inspeção: apenas olhando o código-fonte e tentando encontrar algum ponto que parece necessitar melhoria. Desta maneira você invariavelmente estará errado. Utilizar um perfilador (profiler) para obter uma lista detalhada do que o seu aplicativo realmente faz é o único modo de se ter certeza.

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.
pt_BR: Geralmente o problema é isolado a pequenas seções do código. Primeiro escolha o pior local e se concentre nisso. Uma vez terminado, execute novamente o perfilador (profiler) e repita. À medida que você prossegue os ganhos realizados a cada etapa vão se tornando cada vez menores, até que em certo ponto você terá que decidir se os resultados são bons o bastante. Se os seus esforços estão apenas extraindo 10% de melhorias, então você está bem além do ponto do qual deveria 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.
pt_BR: Não se esqueça do todo, da perspectiva global. Por exemplo, ao invés de simplesmente tentar acelerar um trecho do código, pergunte a você mesmo se ele precisa ser executado completamente. Ele pode ser combinado com outro trecho de código? Os resultados de cálculos anteriores podem ser salvos e re-utilizados? Ele sequer precisa ser otimizado se estiver em um local onde o usuário nunca irá percebê-lo. Pior ainda, o código já pode estar otimizado e agora estar realizando cálculos pesados para evitar fazê-los novamente mais tarde. O código não é executado isoladamente, quanto menos o processo de otimização.

note: (itstool) path: section/title
en: Hints
pt_BR: Dicas

note: (itstool) path: item/title
en: The Fundamentals
pt_BR: Os fundamentos

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.
pt_BR: Execute novamente a sua avaliação de desempenho depois de cada mudança que você tenha realizado no código-fonte e mantenha um registro de tudo que você tenha alterado e como isto afeta a avaliação de desempenho. Isto permite que você desfaça erros e também o ajuda a não repetir erros.

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.
pt_BR: Certifique-se de que seu código-fonte está correto e livre de erros antes de otimizá-lo. Verifique ainda se ele permanece correto e livre de erros após a otimização.

note: (itstool) path: item/p
en: Optimize at the high level before optimizing the details.
pt_BR: Otimize o nível mais alto antes de otimizar os detalhes.

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.
pt_BR: Utilize o algoritmo correto. O exemplo clássico dos livros de texto é utilizar quick-sort ao invés de bubble-sort. Há muitos outros, alguns economizam memória, alguns poupam a CPU. Ademais, visualize quais atalhos você pode tomar: você pode fazer mais rápido que ordenação-rápida (quick-sort) se estiver preparado para fazer algumas concessões.

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.
pt_BR: Otimização é um dilema. Armazenar em cache os resultados aceleram os cálculos, mas aumentam a utilização de memória. Salvar os dados em disco economiza a memória, mas custa tempo para carregar de volta a partir do 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.
pt_BR: Certifique-se de que você escolheu uma ampla variedade de entradas em relação a otimização. Se você não escolheu, é fácil terminar com uma parte do código cuidadosamente otimizada para um arquivo e não 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.
pt_BR: Evite operações que custam muito: muitas leituras pequenas em disco. Utilizar muitas porções de memória acarretando que o swap de disco torne-se necessário; Evite qualquer coisa que escreva ou leia a partir do disco rígido desnecessariamente; A rede também é lenta; Evite também operações gráficas que precisem de uma resposta do servidor X.

note: (itstool) path: item/title
en: Traps for the Unwary
pt_BR: Armadilhas para os descuidados

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.
pt_BR: Cuidado com os efeitos colaterais. Muitas vezes podem ocorrer interações estranhas entre diferentes trechos do código, uma aceleração em uma parte pode desacelerar outra parte.

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.
pt_BR: Ao cronometrar o código, mesmo em um sistema silencioso, eventos fora do programa acrescentam ruído aos resultados de tempo. Faça a média a partir de múltiplas execuções. Se o código é bem pequeno, a resolução do temporizador também é um problema. Neste caso, meça o tempo que o computador leva para executar o código 100 ou 1000 vezes. Se o tempo que você está registrando é maior que alguns segundos, você deve estar correto.

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.
pt_BR: É muito fácil ser iludido pelo perfilador (profiler). Existem histórias de pessoas otimizando o loop ocioso do sistema operacional porque é o local onde se é gasto todo o tempo! Não otimize código que não é relevante para o usuário.

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.
pt_BR: Lembre-se dos recursos no servidor X. A utilização de memória do seu programa não inclui os pixmaps que estão armazenados no processo do servidor X, mas eles ainda estão utilizando memória. Utilize xrestop para verificar quais recursos seu programa está utilizando.

note: (itstool) path: item/title
en: Low Level Hints
pt_BR: Dicas de baixo nível

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.
pt_BR: Ao otimizar utilização de memória, seja cauteloso em relação a diferença entre o pico de utilização e o uso médio de memória. Se uma porção de memória está sempre alocada, isto geralmente é ruim. Caso seja apenas brevemente alocada, então isto pode ser bem aceitável. Ferramentas como massif utilizam o conceito de espaço-tempo, o produto da memória utilizada e a duração a qual ela foi alocada para isso.

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.
pt_BR: Cronometre pedaços simples de código que apenas fazem coisas que você sabe que são necessárias, isto oferece um menor limite absoluto sobre o tempo que seu código irá ter. Por exemplo: ao otimizar um loop, cronometre o loop vazio. Caso isto ainda leve muito tempo, nenhum montante de pequenas otimizações irá ajudar e você precisará alterar sua análise de projeto. Certifique-se de que o compilador não piora seu loop vazio.

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.
pt_BR: Mova o código para fora de loops internos. Um pedaço de código levemente mais complicado que é executado uma vez é mais rápido que um trecho de código simples executado mil vezes. Evite chamar códigos lentos com frequência.

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.
pt_BR: Forneça ao compilador a maior quantidade de dicas possível. Utilize a palavra-chave “const”. Para pequenas funções, que são frequentemente chamadas, utilize <code>G_INLINE_FUNC</code>. Consulte <code>G_GNUC_PURE</code>, <code>G_LIKELY</code> e as outras diversas macros do glib. Para garantir portabilidade, utilize as macros ao invés das palavras-chave específicas do gcc.

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).
pt_BR: Não utilize linguagem Assembly. Ela não é portável e, enquanto pode ser rápido em um processador, nem sempre é garantido que será rápido em cada processador que suporte aquela arquitetura (ex: Athlon versus 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.
pt_BR: Não sobrescreva uma rotina já existente de uma biblioteca a menos que você tenha certeza que ela é desnecessariamente lenta. Muitas rotinas de biblioteca que fazem uso intensivo de CPU já foram otimizadas. Em contrapartida algumas rotinas de bibliotecas são lentas, especialmente as que realizam chamadas de sistema ao sistema operacional.

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.
pt_BR: Reduza o número de bibliotecas as quais você se referencia. Quanto menos bibliotecas forem referenciadas, mais rápido o programa se iniciará. Isto é uma coisa difícil de se fazer no GNOME.

note: (itstool) path: item/title
en: High Level Tricks
pt_BR: Truques de alto nível

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.
pt_BR: Tire vantagem da concorrência. Isto não significa apenas utilizar múltiplos processadores, isto também significa aproveitar do tempo que o usuário gasta pensando sobre o que ele irá fazer depois, para executar alguns cálculos antecipadamente. Faça cálculos enquanto espera por dados a serem carregados para fora do disco. Tire proveito dos muitos recursos, use todos eles ao mesmo tempo.

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.
pt_BR: Iluda. O usuário apenas precisa pensar que o computador é rápido, não importa se ele realmente é ou não. O importante é o tempo entre o comando e a resposta, não interessa se a resposta foi calculada antecipadamente, utilizado cache, ou será de fato trabalhada mais tarde em um tempo mais conveniente, contanto que o usuário obtenha o 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.
pt_BR: Faça coisas no loop ocioso. Isto é mais fácil de programar do que utilizar múltiplas threads completas mas ainda assim resolvem as coisas fora da vista dos usuários. Entretanto seja cuidadoso, se você perder muito tempo no loop ocioso seu programa se tornará lento. Então regularmente ofereça o controle de volta ao loop 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.
pt_BR: Se tudo isso falhar, diga ao usuário que o código vai tornar-se lento e coloque uma barra de progresso. Eles não vão ficar tão felizes quanto se você tivesse apenas apresentado os resultados, porém pelo menos eles saberão que o programa não travou, eles podem ir buscar um copo de café.

note: (itstool) path: page/title
en: Using <app>Massif</app> for Profiling Memory Use in GNOME Software
pt_BR: Utilizando <app>Massif</app> para perfilar utilização de memória em software do 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.
pt_BR: <app>Massif</app> é um membro da suíte de ferramentas de perfilamento de memória <link href="http://valgrind.org/">valgrind</link>. Seu propósito é fornecer uma visão detalhada da utilização de memória dinâmica durante o tempo de vida do programa. Especificamente, ele grava a utilização de heap e de stack (pilha) da memória.

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.
pt_BR: O heap é a região da memória que é alocada com funções como malloc. Ele cresce por demanda e geralmente é a maior região de memória em um programa. A pilha (stack) é onde são armazenados todos os dados locais para as funções. Isto inclui as variáveis “automáticas” em C e os endereços de retorno para as sub-rotinas. A pilha é tipicamente bem menor e muito mais ativa que o heap. Nós não vamos considerar explicitamente como pilha já que o <app>Massif</app> o trata como se fosse apenas outra parte do heap. <app>Massif</app> também fornece informações sobre quanta memória é utilizada para gerenciar o heap.

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.
pt_BR: O <app>Massif</app> produz dois arquivos de saída: um resumo gráfico em um arquivo postscript e uma discriminação detalhada em um arquivo de texto.

note: (itstool) path: section/title
en: Using <app>Massif</app> with GNOME
pt_BR: Utilizando o <app>Massif</app> com o 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.
pt_BR: <app>Massif</app> possui muitas poucas opções e para muitos programas elas não são necessárias. Entretanto para aplicativos GNOME, onde a alocação de memória pode estar enterrada nas profundezas do glib ou GTK, os descendentes do Massif precisam ser aumentados a medida que o número de níveis da pilha de chamadas abaixam. Isto é alcançado usando o parâmetro --depth. Por padrão, este valor é 3; aumentando ele para 5 irá garantir que a pilha de chamadas atinja o seu código. Mais um ou dois níveis podem ser convenientes para fornecer algum contexto ao seu código. Uma vez que o nível de detalhamento se torna rapidamente sobrecarregado, é melhor iniciar com o parâmetro de menor profundidade (depth) e apenas aumentá-lo quando se torna aparente que isto não é suficiente.

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.
pt_BR: Também é útil avisar o <app>Massif</app> quais funções alocam memória no glib. Isto remove uma camada desnecessária de chamadas de função dos relatórios e oferece a você uma ideia mais clara de qual código está alocando memória. As funções de alocação do glib são: g_malloc, g_malloc0, g_realloc, g_try_malloc e g_mem_chunk_alloc. Você utiliza a opção --alloc-fn para contar ao Masiff sobre elas.

note: (itstool) path: section/p
en: Your command-line should therefore look something like:
pt_BR: A partir de agora, sua linha de comando deve parecer como algo assim:

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.
pt_BR: <app>Swell Foop</app> é o programa que estaremos utilizando como exemplo. Esteja avisado de quê, uma vez que valgrind emula a CPU, ele irá rodar <em>muito</em> lentamente. Você precisará também de muita memória.

note: (itstool) path: section/title
en: Interpreting the Results
pt_BR: Interpretando os 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.
pt_BR: A saída gráfica do <app>Massif</app> é amplamente auto-explicativa. Cada faixa representa a memória alocada para uma função em relação ao tempo. Uma vez que você identifique quais faixas estão usando a maior parte da memória, geralmente a mais espessa ao topo, você terá de consultar o arquivo de texto para os detalhes.

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.
pt_BR: O arquivo de texto é organizado em hierarquia de seções, ao topo há uma lista dos piores usuários de memória dispostos em espaço-tempo decrescente. Abaixo disso há mais seções, cada qual decompondo os resultados em detalhes mais sutis a medida que você prossegue para a porção inferior da pilha de chamadas. Para esclarecer isto, nós utilizaremos a saída do comando supra-citado.

note: (itstool) path: figure/title
en: <app>Massif</app> output for the unoptimized version of the <app>Swell Foop</app> program.
pt_BR: Saída do <app>Massif</app> para a versão não otimizada do programa <app>Swell Foop</app>.

[ctx: _]
note: (itstool) path: figure/media This is a reference to an external file such as an image or video. When the file changes, the md5 hash will change to let you know you need to update your localized copy. The msgstr is not used at all. Set it to whatever you like once you have updated your copy of the fi
en: external ref='figures/massif-before.png' md5='1a6b2ace548e6789ab8bfacb3727b345'
pt_BR: external ref='figures/massif-before.png' md5='9619664b823f195ef9227e3d8bb051b1'

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.
pt_BR: A imagem acima mostra uma saída postscript típica do <app>Massif</app>. Este é o resultado que você obteria ao jogar um único jogo do <app>Swell Foop</app> (versão 2.8.0) e depois saindo. O arquivo postscript terá um nome como <file>massif.12345.ps</file> e o arquivo de texto será chamado <file>massif.12345.txt</file>. O número ao meio é o ID do processo do programa que foi examinado. Se você realmente tentar realizar este exemplo, você encontrará duas versões para cada arquivo com números levemente diferentes, devido o <app>Swell Foop</app> iniciar um segundo processo e o <app>Massif</app> o seguir também. Nós iremos ignorar este segundo processo, ele consome muito pouca memória.

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:
pt_BR: Ao topo do gráfico, nós vemos uma ampla faixa amarela rotulada gdk_pixbuf_new. Ela parece ser uma candidata ideal para otimização, mas nós iremos precisar utilizar o arquivo de texto para descobrir o que está chamando gdk_pixbuf_new. O topo do arquivo de texto irá se parecer como algo assim:

note: (itstool) path: section/code
en: 
    Command: ./swell-foop
    
    == 0 ===========================
    Heap allocation functions accounted for 90.4% of measured spacetime
    
    Called from:
      28.8% : 0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
    
        6.1% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)
    
        5.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)
    
        3.5% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)
pt_BR: 
    Comando: ./swell-foop
    
    == 0 ===========================
    Heap allocation functions accounted for 90.4% of measured spacetime
    
    Called from:
      28.8% : 0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)
    
        6.1% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)
    
        5.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)
    
        3.5% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)

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:
pt_BR: A linha com o sinal de '=' indica a que distância abaixo do rastreamento da pilha estamos, neste caso estamos ao topo. Após isto, são listados os usuários de memória mais pesados em ordem decrescente em relação ao tempo. O espaço-tempo é o produto da quantidade de memória utilizada e por quanto tempo ela foi utilizada. Isto corresponde a área das faixas no gráfico. Esta parte do arquivo nos conta o que já sabíamos: a maior parte do espaço-tempo é dedicado ao gdk_pixbuf_new. Para descobrir o que chamou o gdk_pixbuf_new nós precisamos pesquisar, logo abaixo, o arquivo 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.
pt_BR: A primeira linha nos conta que agora estamos quatro níveis dentro da pilha. Abaixo há uma listagem das chamadas de função que partem daqui até o gdk_pixbuf_new. Finalmente há uma lista de funções que estão no próximo nível inferior e chamam estas funções. Também existem, obviamente, entradas para os níveis 1, 2 e 3, mas este é o primeiro nível a alcançar logo abaixo, através do código GDK, o código do <app>Swell Foop</app>. A partir desta listagem, nós podemos ver instantaneamente que o problema do código é o 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.
pt_BR: Agora que sabemos qual parte do nosso código está utilizando todo o espaço-tempo, nós podemos olhar para ele e descobrir o porquê. Verifica-se que o load_scenario está carregando um pixbuf a partir do arquivo e então nunca liberando aquela memória. Tendo sido identificado o código problemático, nós podemos começar a consertá-lo.

note: (itstool) path: section/title
en: Acting on the Results
pt_BR: Atuando 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.
pt_BR: Reduzir o consumo de espaço-tempo é bom, porém há duas formas de reduzi-lo e elas não são iguais. Você pode tanto reduzir a quantidade de memória alocada ou reduzir o montante de tempo que é alocado para isto. Por um momento, considere um modelo de sistema com apenas dois processos em execução. Ambos os processos utilizam quase toda a memória RAM física e se eles se sobrepõem completamente, então o sistema irá utilizar a memória de troca (swap) e tudo vai ficar lento. Obviamente, se nós reduzimos a utilização de memória de cada processo por um fator de dois, então eles podem coexistir pacificamente sem a necessidade de utilizar a memória de troca (swap). Se ao invés disso, nós reduzimos o tempo o qual a memória é alocada por um fator de dois, então os dois programas podem coexistir, mas apenas enquanto seus períodos de alta utilização de memória não sobreporem-se. Logo, é melhor reduzir o montante de memória alocada.

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.
pt_BR: Infelizmente, a escolha de otimização também é reprimida pelas necessidades do programa. O tamanho dos dados do pixbuf no <app>Swell Foop</app> é determinado pelo tamanho dos gráficos do jogo e não pode ser reduzido facilmente. Entretanto, a quantidade de tempo que ele gasta sendo carregado para dentro da memória, pode ser drasticamente reduzido. A imagem abaixo mostra a análise feita pelo <app>Massif</app> do <app>Swell Foop</app> após se dispor do pixbufs, uma vez que as imagens foram carregadas dentro do servidor X.

note: (itstool) path: figure/title
en: <app>Massif</app> output for the optimized <app>Swell Foop</app> program.
pt_BR: Saída do <app>Massif</app> para o programa <app>Swell Foop</app> otimizado.

[ctx: _]
note: (itstool) path: figure/media This is a reference to an external file such as an image or video. When the file changes, the md5 hash will change to let you know you need to update your localized copy. The msgstr is not used at all. Set it to whatever you like once you have updated your copy of the fi
en: external ref='figures/massif-after.png' md5='36d1b4ad7ab49b28b69ad3eabbaa7069'
pt_BR: external ref='figures/massif-after.png' md5='a91df704217641ea8fa93d90031121bd'

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.
pt_BR: A utilização de espaço-tempo do gdk_pixbuf_new é agora uma faixa fina que apenas sofre picos de forma leve (é a décima-sexta faixa para baixo e sombreada de magenta). Como bônus, o pico de utilização de memória caiu 200 kB, já que o pico ocorre antes de outra memória ser alocada. Se dois processos como este são executados juntos, as chances do pico de utilização de memória coincidirem, e por isso o risco de usar memória de troca (swap), seriam bastante baixos.

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.
pt_BR: Nós podemos fazer melhor? Uma verificação rápida na saída de texto do <app>Massif</app> revela: g_strdup como o novo maior ofensor.

note: (itstool) path: section/code
en: 
    Command: ./swell-foop
    
    == 0 ===========================
    Heap allocation functions accounted for 87.6% of measured spacetime
    
    Called from:
        7.7% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)
    
        7.6% : 0x43BC9F: (within /usr/lib/libgdk-x11-2.0.so.0.400.9)
    
        6.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)
    
        5.2% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)
pt_BR: 
    Comando: ./swell-foop
    
    == 0 ===========================
    Heap allocation functions accounted for 87.6% of measured spacetime
    
    Called from:
        7.7% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)
    
        7.6% : 0x43BC9F: (within /usr/lib/libgdk-x11-2.0.so.0.400.9)
    
        6.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)
    
        5.2% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)

note: (itstool) path: section/p
en: If we look closer though we see that it is called from many, many, places.
pt_BR: Se olhamos mais de perto, observamos que ele é chamado de muitos, muitos, lugares.

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.
pt_BR: Agora nós nos deparamos com retornos cada vez menores para os nossos esforços de otimização. O gráfico sugere outra possível abordagem: Tanto as faixas “outros” e “gerenciamento de heap” são bem grandes. Isto nos diz que há um monte de pequenas alocações sendo feitas a partir de uma variedade de lugares. Eliminá-las será difícil porém se elas puderem ser agrupadas, então as alocações individuais poderão ser maiores e a elevada faixa “gerenciamento de heap” poderá ser reduzida.

note: (itstool) path: section/title
en: Caveats
pt_BR: Advertências

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.
pt_BR: Existem um par de coisas as quais devemos ficar atentos: Primeiramente, espaço-tempo é apenas informado como uma porcentagem, você deve compará-lo ao tamanho total do programa, para decidir se vale a pena você ir atrás de quantidade de memória. O gráfico, com seu eixo vertical em kilobytes, é bom para isto.

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.
pt_BR: Em segundo lugar, o <app>Massif</app> apenas leva em consideração a memória utilizada pelo seu próprio programa. Recursos como pixmaps são armazenados no servidor X e não são considerados pelo <app>Massif</app>. No exemplo do <app>Swell Foop</app> nós realmente só mudamos o consumo de memória do lado do cliente do pixbufs para o lado do servidor pixmaps. Apesar de termos trapaceado, ocorreram ganhos de performance. Manter os dados de imagem no servidor X, faz com que as rotinas dos gráficos fiquem mais rápidas e remove uma grande quantidade de comunicações entre processos (ipcs). Ademais, os pixmaps serão armazenados em um formato gráfico nativo que geralmente é mais compacto que o formato RGBA de 32-bits utilizado pelo gdk_pixbuf. Para medir o efeito de pixmaps, e outros recursos X, utilize o programa <link href="http://www.freedesktop.org/Software/xrestop">xrestop</link>.
