gnome-devel-docs master - en to de_DE translation catalogue (90 entries)

note: (itstool) path: page/title
en: Disk Seeks Considered Harmful
de_DE: Laufwerkszugriffe werden als nachteilig angesehen

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:
de_DE: Laufwerkszugriffe sind die wohl aufwändigsten Vorgänge, die Sie überhaupt ausführen können. Sie wissen das womöglich nicht aufgrund der Anzahl der Ausführungen, aber glauben Sie mir, dass sie es sind. Folglich vermeiden Sie bitte das folgende ungünstige Verhalten:

note: (itstool) path: item/p
en: Placing lots of small files all over the disk.
de_DE: Viele kleine Dateien auf dem gesamten Laufwerk verteilen.

note: (itstool) path: item/p
en: Opening, stating, and reading lots of files all over the disk
de_DE: Öffnen, stat() ausführen und lesen vieler Dateien vom gesamten Laufwerk

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.
de_DE: Obiges mit Dateien tun, die zu verschiedenen Zeitpunkten erstellt wurden, so dass sie fragmentiert sind und noch mehr Plattenaktivität verursachen.

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.
de_DE: Obiges mit Dateien tun, die sich in verschiedenen Ordnern befinden, so dass auf verschiedene Zylindergruppen zugegriffen wird und so noch mehr Plattenaktivität verursacht wird.

note: (itstool) path: item/p
en: Repeatedly doing the above when it only needs to be done once.
de_DE: Wiederholt obiges tun, obwohl es nur einmal getan werden muss.

note: (itstool) path: page/p
en: Ways in which you can optimize your code to be seek-friendly:
de_DE: Mögliche Wege, wie Sie Ihren Code suchfreundlich optimieren können:

note: (itstool) path: item/p
en: Consolidate data into a single file.
de_DE: Fassen Sie Daten in einer einzigen Datei zusammen.

note: (itstool) path: item/p
en: Keep data together in the same directory.
de_DE: Halten Sie Daten im gleichen Ordner vor.

note: (itstool) path: item/p
en: Cache data so as to not need to reread constantly.
de_DE: Speichern Sie Daten zwischen, so dass sie nicht fortwährend erneut eingelesen werden müssen.

note: (itstool) path: item/p
en: Share data so as not to have to reread it from disk when each application loads.
de_DE: Geben Sie Daten frei, so dass sie nicht beim Laden von Anwendungen immer wieder erneut gelesen werden müssen.

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.
de_DE: Erwägen Sie, alle Daten in einer einzigen Binärdatei zwischenzuspeichern, die sauber aufgebaut ist und mit mmap verarbeitbar ist.

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.
de_DE: Die Probleme mit Plattenzugriffen verstärken sich beim Lesen, was wir leider eben gerade tun. Merken Sie sich, dass im Allgemeinen Lesen synchron und Schreiben asynchron verläuft. Das verschlimmert nur das Problem mit jedem seriellen Lesevorgang und trägt zu Programmverzögerungen bei.

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.
de_DE: Das vorliegende Dokument kann gemäß den Bedingungen der GNU Free Documentation License (GFDL), Version 1.1 oder jeder späteren, von der Free Software Foundation veröffentlichten Version ohne unveränderbare Abschnitte sowie ohne Texte auf dem vorderen und hinteren Buchdeckel kopiert, verteilt und/oder modifiziert werden. Eine Kopie der GFDL finden Sie auf der <link href="http://www.fsf.org">Webseite der Free Software Foundation</link> oder schreiben Sie an: 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.
de_DE: Bei vielen der von Firmen zur Unterscheidung ihrer Produkte und Dienstleistungen verwendeten Namen handelt es sich um Marken. An den Stellen, an denen derartige Namen in einer GNOME-Dokumentation vorkommen und wenn die Mitglieder des GNOME-Dokumentationsprojekts über diese Marken informiert wurden, sind die Namen in Großbuchstaben oder mit großen Anfangsbuchstaben geschrieben.

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.
de_DE: Die Optimierung von Software kann verschiedene Ziele verfolgen: Geschwindigkeit, Programmgröße oder Speicherverbrauch. Dieser Abschnitt enthält Leitfäden und Anleitungen zum Optimieren Ihrer Software.

note: (itstool) path: page/title
en: Optimization Guide
de_DE: Optimierungs-Handbuch

note: (itstool) path: section/title
en: Introduction
de_DE: Einführung

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.
de_DE: Dies ist eine kurze Einführung in die Optimierung und behandelt sowohl das Wie als auch das Warum. Details zu individuellen Werkzeugen verschieben wir auf spätere Artikel, eine Sammlung aus Hinweisen und Tricks ist jedoch enthalten.

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.
de_DE: Dieser Artikel beschreibt, wie Sie den Heap-Profiler <app>Massif</app> mit GNOME-Anwendungen verwenden. Wir beschreiben den Aufruf, die Interpretation und die Möglichkeiten, die Ausgaben von <app>Massif</app> richtig zu nutzen. Das Spiel <app>Swell Foop</app> wird als Beispiel verwendet.

note: (itstool) path: section/title
en: Harmfulness
de_DE: Schädlichkeit

note: (itstool) path: page/title
en: What are we Optimizing?
de_DE: Was optimieren wir?

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.
de_DE: Sie sollten bei der Optimierung für GNOME zunächst eines bedenken: Wir versuchen nicht, das Programm zu verbessern, sondern wir versuchen, die Benutzer glücklicher zu machen.

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.
de_DE: Bessere Programme machen die Benutzer glücklicher, aber es gibt Verbesserungsmöglichkeiten, die sie viel glücklicher machen werden als Andere: Ansprechzeit, Startzeit, leichter Zugriff auf Befehle. Der Rechner sollte auch nicht sofort den Auslagerungsspeicher benutzen müssen, wenn mehr als eine Anwendung geöffnet ist.

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.
de_DE: Die traditionelle Optimierung umfasst Konzepte wie Prozessorlast, Umfang des Codes, die Anzahl der Mausklicks sowie die Speichernutzung des Programms. Die folgende Auflistung sollte die erste Liste ergänzen, wobei ein grundlegender Unterschied besteht: Ein GNOME-Benutzer schenkt der zweiten Liste keine Beachtung, während der ersten Liste sehr wohl Aufmerksamkeit gewidmet wird. Beim Optimieren von GNOME-Programmen sollen die Prozessorlast, der Speicherverbrauch und all diese Dinge optimiert werden, aber das sind die Bedeutungen, nicht das Endziel. Wir optimieren für Benutzer.

note: (itstool) path: section/title
en: Doing the Optimization
de_DE: Ausführung der Optimierung

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.
de_DE: Aus dem vorigen Abschnitt wurde deutlich: Um etwas optimieren zu können, muss es messbar sein. Sie können Zufriedenheit nicht messen, aber Sie können sehr wohl Startzeiten messen, um sagen zu können, dass Sie sie verbessert haben. Die Zufriedenheit wird dann - hoffentlich - folgen.

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.
de_DE: Optimierung ist ein Prozess des Messens, der Verfeinerung und erneuten Messens. Daher müssen Sie zunächst einen Weg finden, das zu messen, was Sie optimieren wollen. Idealerweise ist dieser Messwert eine einzige Zahl, beispielsweise die Zeit, die für die Ausführung einer Aufgabe benötigt wird. Dies ist Ihr Maßstab, es ist der einzige Weg festzustellen, ob Sie auf der Gewinner- oder der Verliererseite sind. Es ist ein sehr wesentlicher Unterschied, ob ein Programm schnell sein <em>sollte</em> oder ob es tatsächlich schnell <em>ist</em>.

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.
de_DE: Sobald Sie einen Ausgangsmaßstab gefunden haben, müssen Sie nun herausfinden, warum Ihr Code seine Aufgabe nicht so gut erledigt, wie er es eigentlich sollte. Es ist verlockend, dies durch eine einfache Sichtung zu tun: Sich den Code anzuschauen und etwas zu finden, dass verbesserungswürdig scheint. Doch Sie werden immer falsch liegen. Der einzig sichere Weg ist es, einen Profiler für eine detaillierte Aufschlüsselung der Programmaktivitäten zu verwenden.

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.
de_DE: Gewöhnlich ist das Problem auf kleine Code-Abschnitte beschränkt. Wählen Sie den schlimmsten Teil und konzentrieren Sie sich zuerst darauf. Führen Sie den Profiler erneut aus und wiederholen Sie den Arbeitsschritt, sobald dies erledigt ist. Wenn Sie so arbeiten, werden die Gewinne mit jedem Schritt geringer. Ab einem bestimmten Punkt müssen Sie entscheiden, dass die Ergebnisse gut genug sind. Wenn Ihre Bemühungen nur 10% Verbesserung ergeben, dann sind Sie bereits weit über den Punkt hinaus, wo Sie hätten stoppen sollen.

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.
de_DE: Vergessen Sie nicht das Gesamtbild. Zum Beispiel sollten Sie sich fragen, ob der Code überhaupt unbedingt ausgeführt werden muss, statt seine Geschwindigkeit zu verbessern. Kann er mit anderem Code kombiniert werden? Können bereits ausgeführte Berechnungen gespeichert und später wieder verwertet werden? Eine Optimierung kann man sich auch sparen, wenn der Code dort ausgeführt wird, wo ihn der Benutzer niemals bemerken wird. Noch schlimmer, der Code ist eventuell bereits optimiert und führt kostspielige Berechnungen jetzt aus, um dies später zu vermeiden. Code läuft nicht isoliert und ebenso wenig der Optimierungsprozess.

note: (itstool) path: section/title
en: Hints
de_DE: Hinweise

note: (itstool) path: item/title
en: The Fundamentals
de_DE: Die Grundlagen

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.
de_DE: Bilden Sie einen Maßstab nach jeder Code-Änderung aus und führen Sie Buch über alle Änderungen, und wie sie den Maßstab beeinflussen. So können Sie Fehler rückgängig machen und in Zukunft erst gar nicht wiederholen.

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.
de_DE: Stellen Sie sicher, dass Ihr Code korrekt und fehlerfrei ist, bevor Sie mit der Optimierung beginnen. Überprüfen Sie nach der Optimierung, ob dies dann auch noch zutrifft.

note: (itstool) path: item/p
en: Optimize at the high level before optimizing the details.
de_DE: Optimieren Sie zunächst auf hoher Ebene, bevor es an die Details geht.

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.
de_DE: Verwenden Sie den passenden Algorithmus. Das klassische Beispiel ist, Quick-Sort statt Bubble-Sort zu verwenden. Es gibt viele andere. Einige belegen wenig Arbeitsspeicher, andere brauchen wenig Rechenleistung. Schauen Sie auch, ob Sie Kompromisse eingehen können: Es geht auch schneller als Quick-Sort.

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.
de_DE: Optimierungen sind ein Abwägen. Ergebnisse zwischenzuspeichern beschleunigt Berechnungen, aber erhöht den Speicherverbrauch. Daten auf einen Datenträger zu speichern spart Arbeitsspeicher, aber kostet Zeit beim Laden vom Datenträger.

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.
de_DE: Wählen Sie unbedingt eine große Vielfalt an Eingangsgrößen, die Sie optimieren. Wenn Sie dies nicht tun, können Sie schnell mit einem sorgfältig für nur eine einzige Datei optimierten Code enden.

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.
de_DE: Vermeiden Sie aufwändige Vorgänge: Mehrere kleine Plattenlesevorgänge, Belegung von sehr viel Arbeitsspeicher, bis das Auslagern beginnt. Vermeiden Sie unnötige Schreib- und Lesevorgänge auf Datenträger. Das Netzwerk ist auch langsam. Vermeiden Sie auch grafische Operationen, die eine Antwort vom X-Server erfordern.

note: (itstool) path: item/title
en: Traps for the Unwary
de_DE: Fallen für die Unvorsichtigen

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.
de_DE: Nehmen Sie sich vor Nebeneffekten in Acht. Es kann oft seltsame Interaktionen zwischen verschiedenen Code-Bereichen geben. Eine Geschwindigkeitsverbesserung in einem Teil kann einen anderen Teil ausbremsen.

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.
de_DE: Beim zeitlichen Abstimmen von Code - auch auf unbelasteten Systemen - sorgen externe Ereignisse für Unregelmäßigkeiten bei der Zeitplanung. Bilden Sie Durchschnittswerte von mehreren Durchläufen. Wenn der Code sehr kurz ist, so kann die Zählergenauigkeit zu einem Problem werden. In diesem Fall messen Sie die Zeit 100 oder 1000 Mal, die der Rechner zur Abarbeitung braucht. Wenn Sie Zeitspannen von einigen Sekunden messen, dann sind Sie im grünen Bereich.

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.
de_DE: Es ist sehr leicht, vom Profiler in die Irre geführt zu werden. Es gibt Geschichten über Leute, die die Untätigkeitsphase perfekt optimiert haben, weil das Programm ja die meiste Zeit in Untätigkeit verbringt! Optimieren Sie keinen Code, von dessen Wirkung der Benutzer ohnehin keine Notiz nimmt.

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.
de_DE: Vergessen Sie nicht den Ressourcenverbrauch des X-Servers. Der Speicherverbrauch Ihres Programms enthält nicht die Pixmaps, die vom X-Server verarbeitet werden, aber sie verbrauchen dennoch Speicher. Verwenden Sie <command>xrestop</command>, um zu sehen, welche Ressourcen Ihr Programm beansprucht.

note: (itstool) path: item/title
en: Low Level Hints
de_DE: Tipps mit niedrigem Niveau

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.
de_DE: Seien Sie bei der Optimierung des Speicherverbrauchs umsichtig bezüglich des Unterschieds zwischen Spitzen- und durchschnittlicher Speicherbelegung. Einiger Speicher wird quasi immer belegt, das ist nicht gut. Einiger wird nur kurzzeitig belegt, dies ist in Ordnung. Werkzeuge wie »massif« verwenden das Raum-Zeit-Konzept, d.h. das Produkt von belegtem Arbeitsspeicher und der Belegungsdauer.

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.
de_DE: Stoppen Sie die Zeit vereinfachter Code-Teile, die nur Entscheidendes erledigen. Dies legt eine absolute untere Grenze für die Laufzeit Ihres Codes fest. Zum Beispiel sollten Sie beim Optimieren einer Schleife die leere Schleife stoppen. Wenn dies immer noch zu lang ist, dann wird keine Mikro-Optimierung Abhilfe schaffen und Sie müssen das grundlegende Design ändern. Stellen Sie sicher, dass der Compiler dabei nicht ihre leeren Schleifen rationalisiert.

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.
de_DE: Gliedern Sie Code aus Schleifen aus. Ein etwas umfangreicheres Stück Code, das nur einmal ausgeführt wird, ist um Einiges schneller als ein simples Stück Code, was dafür tausend Schleifen durchläuft. Vermeiden Sie es, langsamen Code allzu oft aufzurufen.

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.
de_DE: Geben Sie dem Compiler so viele Hinweise wie möglich. Verwenden Sie das const-Schlüsselwort. Verwenden Sie <code>G_INLINE_FUNC</code> für kurze, häufig aufgerufene Funktionen. Schauen Sie nach <code>G_GNUC_PURE</code>, <code>G_LIKELY</code> und weiteren diversen glib-Makros. Verwenden Sie diese Makros anstelle der gcc-spezifischen Schlüsselwörter, um die Portierbarkeit zu erhalten.

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).
de_DE: Verwenden Sie keine Assemblersprachen. Sie sind nicht portierbar. Während sie auf dem einen Prozessor unglaublich schnell sind, ist nicht unbedingt garantiert, dass dies auf jedem von der Architektur unterstützten Prozessor genauso ist (beispielsweise Athlon vs Pentium 4).

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.
de_DE: Schreiben Sie eine vorhandene Bibliotheksroutine nicht neu, es sei denn, Sie sind sich sicher, dass sie unakzeptabel langsam ist. Viele prozessorintensive Bibliotheksroutinen wurden bereits optimiert. Andererseits sind einige Routinen tatsächlich langsam, insbesondere diejenigen, die Systemaufrufe an das Betriebssystem absetzen.

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.
de_DE: Halten Sie die Zahl der verlinkten Bibliotheken gering. Je weniger Bibliotheken gelinkt werden müssen, umso schneller startet das Programm. Dies ist in GNOME allerdings schwierig.

note: (itstool) path: item/title
en: High Level Tricks
de_DE: Tricks auf hohem Niveau

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.
de_DE: Nutzen Sie Nebenläufigkeit aus. Das bedeutet nicht nur mehrere Prozessoren zu verwenden, es bedeutet auch die Zeit auszunutzen, in welcher der Anwender über seine weiteren Aktivitäten nachdenkt, und in Vorausschau einige Berechnungen auszuführen. Führen Sie Berechnungen aus, während Daten vom Datenträger geladen werden. Nutzen Sie verschiedene Ressourcen, wenn vorhanden, gleichzeitig.

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.
de_DE: Bluffen Sie. Der Benutzer sollte denken, dass sein Rechner schnell ist, aber es ist gleich, ob er es wirklich ist oder nicht. Die Zeit zwischen dem Befehl und der darauf folgenden Antwort ist maßgebend. Es ist gleichgültig, ob die Antwort vorausberechnet wird, zwischengespeichert oder in irgendeiner anderen Weise später zu einem günstigeren Zeitpunkt ausgewertet wird, solange der Benutzer genau das bekommt, was er erwartet.

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.
de_DE: Erledigen Sie Dinge in der Idle-Schleife. Dies ist einfacher zu programmieren als Multi-Threading, aber die Dinge geschehen vom Benutzer unbemerkt. Seien Sie jedoch vorsichtig. Wenn Ihr Programm sehr viel Zeit in der Idle-Schleife verbringt, dann wird es träge. Stellen Sie sicher, dass die Kontrolle regelmäßig an die Hauptschleife übergeben wird.

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.
de_DE: Falls alles Andere scheitern sollte, informieren Sie den Benutzer mit einem Fortschrittsbalken drüber, dass es derzeit nur langsam voran geht. Das dürfte ihm lieber sein, als wenn Sie nur die Ergebnisse präsentieren würden. Er möchte zumindest wissen, dass das Programm nicht abgestürzt ist und er dann erst einmal eine Tasse Kaffee trinken gehen kann.

note: (itstool) path: page/title
en: Using <app>Massif</app> for Profiling Memory Use in GNOME Software
de_DE: Verwendung von <app>Massif</app> zur Profilierung des Speicherverbrauchs in GNOME-Software

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.
de_DE: <app>Massif</app> ist Teil der Programmsammlung <link href="http://valgrind.org/">valgrind</link>, die Werkzeuge zur Speicherprofilierung bereitstellt. Zweck ist die Erstellung eines detaillierten Überblicks über die dynamische Speichernutzung während der Lebensdauer eines Programms. Speziell wird der Speicherverbrauch von »heap« und »stack« aufgezeichnet.

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.
de_DE: Der Heap ist der Speicherbereich, der von Funktionen wie »malloc« belegt wird. Er wächst bei Bedarf und ist gewöhnlich der größte Speicherbereich eines Programms. Der Stapelspeicher (Stack) dient zur Speicherung der lokalen Daten von Funktionen. Dies schließt »automatische« Variablen in C und die Rückgabeadresse von Subroutinen ein. Der Stapelspeicher ist typischerweise wesentlich kleiner und deutlich aktiver als der Heap. Wir werden den Stapelspeicher nicht gesondert betrachten, weil ihn <app>Massif</app> wie einen weiteren Teil des Heap ansieht. <app>Massif</app> liefert auch Informationen darüber, wie viel Arbeitsspeicher für den Heap belegt wird.

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.
de_DE: <app>Massif</app> erstellt zwei Ausgabdateien: eine grafische Übersicht in einer PostScript-Datei und eine detaillierte Ausgabe in einer Textdatei.

note: (itstool) path: section/title
en: Using <app>Massif</app> with GNOME
de_DE: <app>Massif</app> mit GNOME verwenden

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.
de_DE: <app>Massif</app> hat sehr wenige Optionen und für viele Programme brauchen Sie diese auch gar nicht. Für GNOME-Anwendungen jedoch muss die Anzahl der Abstiegsebenen des Aufruf-Stapelspeichers erhöht werden, weil sie bei diesen Speicheranforderungen tief in glib oder GTK+ verborgen liegen. Dies wird mit dem Parameter »--depth« erreicht. Die Voreinstellung ist 3; eine Erhöhung auf 5 stellt sicher, dass der Aufruf-Stapelspeicher bis zu Ihrem Code reicht. Ein oder zwei weitere Ebenen können auch wünschenswert sein, um weiteren Kontext zu ersehen. Weil die Detailangaben sehr schnell erdrückend werden können ist es am besten, mit dem kleineren Parameter zu beginnen und ihn nur bei Bedarf zu erhöhen.

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.
de_DE: Es ist auch nützlich, <app>Massif</app> mitzuteilen, welche Funktionen in glib Arbeitsspeicher anfordern. So wird eine unnötige Ebene Funktionsaufrufe aus den Berichten entfernt und verbessert den Einblick, welcher Code Speicher anfordert. Speicher anfordernde Funktionen in glib sind: g_malloc, g_malloc0, g_realloc, g_try_malloc und g_mem_chunk_alloc. Verwenden Sie die Option »--alloc-fn«, um Massif diese Namen mitzuteilen.

note: (itstool) path: section/p
en: Your command-line should therefore look something like:
de_DE: Ihre Befehlszeile sollte daher so aussehen:

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.
de_DE: Das Programm <app>Swell Foop</app> werden wir als Beispiel verwenden. Seien Sie gewarnt: <app>Valgrind</app> emuliert den Prozessor, wodurch es <em>äußerst</em> langsam läuft. Außerdem wird sehr viel Speicher benötigt.

note: (itstool) path: section/title
en: Interpreting the Results
de_DE: Interpretieren der Ergebnisse

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.
de_DE: Die grafische Ausgabe von <app>Massif</app> ist weitgehend selbsterklärend. Jedes Band stellt den einer Funktion zugewiesenen Speicher nach Zeit dar. Sobald Sie herausgefunden haben, welche Bänder den meisten Speicher verbrauchen, üblicherweise die dickeren, oberen, dann schauen Sie sich die Textausgabe für weitere Details an.

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.
de_DE: Die Textdatei ist hierarchisch in Abschnitte gegliedert. Am oberen Ende finden sich die größten Speicherverbraucher, in absteigender Ordnung nach Speicherzeit. Darunter finden sich weitere Abschnitte, die je nach dem Platz im Aufruf-Stack feiner detaillierter sind. Um dies zu verdeutlichen, verwenden wir die Ausgabe des oben stehenden Befehls.

note: (itstool) path: figure/title
en: <app>Massif</app> output for the unoptimized version of the <app>Swell Foop</app> program.
de_DE: <app>Massif</app>-Ausgabe für die nicht optimierte Version des Programms <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'
de_DE: ok

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.
de_DE: Das Bild oben zeigt eine typische PostScript-Ausgabe von <app>Massif</app>. Dies ist das Ergebnis, wenn Sie eine einzige Runde <app>Swell Foop</app> (Version 2.8.0) spielen und dann die Anwendung schließen. Die PostScript-Datei hat einen Namen ähnlich wie <file>massif.12345.ps</file> und die Text-Datei <file>massif.12345.txt</file>. Die Zahl im Dateinamen entspricht der Prozesskennung des untersuchten Programms. Wenn Sie dieses Beispiel nachstellen, so werden Sie zwei Versionen jeder Datei mit leicht verschiedenen Nummern finden. Dies liegt daran, dass <app>Swell Foop</app> einen zweiten Prozess startet und <app>Massif</app> diesen ebenfalls protokolliert. Wie werden diesen zweiten Prozess ignorieren. Er verbraucht nur sehr wenig Speicher.

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:
de_DE: Oben in der Grafik sehen Sie ein großes gelbes Band mit der Bezeichnung gdk_pixbuf_new. Dies schaut nach einem idealen Kandidaten für Optimierungsversuche aus, aber wir werden die Textdatei verwenden müssen, um herauszufinden, wo gdk_pixbuf_new aufgerufen wird. Der Anfang der Textdatei sieht in etwa so aus:

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:
de_DE: Die Zeile mit »=«-Zeichen deutet an, wie tief wir uns in der Stack-Trace befinden. In diesem Fall sind wir ganz oben. Danach werden die größten Speicherbeleger nach absteigender Raumzeit aufgeführt. Raumzeit ist das Produkt der Menge des belegten Speichers und wie lange er belegt wurde. Dies entspricht der Fläche der Bänder im Grafen. Dieser Teil der Datei belegt, was wir bereits wissen: der Großteil der Raumzeit ist gdk_pixbuf_new gewidmet. Um herauszufinden, was gdk_pixbuf_new aufrief, müssen wir weiter unten in der Textdatei suchen:

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.
de_DE: Die erste Zeile besagt, dass wir uns nun vier Ebenen tief im Stapelspeicher befinden. Darunter ist eine Auflistung der Funktionsaufrufe, die von hier bis  gdk_pixbuf_new reichen. Schließlich findet sich eine Liste von Funktionen, die sich eine Ebene darunter befinden und jene Funktionen aufrufen. es gibt natürlich auch Einträge für die Ebenen 1 bis 3, aber dies ist die erste Ebene, die man über den GDK-Code bis zum <app>Swell Foop</app>-Code erreichen kann. Aus der Auflistung kann man sofort erkennen, dass der problematische Code in load_scenario ist.

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.
de_DE: Jetzt, wo wir wissen, welcher Teil unseres Codes alle Raumzeit belegt, können wir ihn betrachten und die Ursache herausfinden. Es stellt sich heraus, dass load_scenario einen Pixbuf aus einer Datei lädt und diesen Speicher nie mehr frei gibt. Nachdem das Problem identifiziert wurde, können wir es beheben.

note: (itstool) path: section/title
en: Acting on the Results
de_DE: Aufgrund der Ergebnisse handeln

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.
de_DE: Ein Reduzieren des Verbrauches an Raumzeit ist gut, aber es gibt zwei verschiedene Wege, dies zu tun. Sie können entweder die angeforderte Speichermenge oder die Belegungszeit reduzieren. Betrachten Sie für einen Moment ein Modellsystem mit nur zwei laufenden Prozessen. Beide Prozesse belegen fast allen physikalischen Arbeitsspeicher und sobald sie sich überlappen, wird das System auslagern müssen und es wird sehr langsam. Es ist offensichtlich, dass die beiden Prozesse friedlich nebeneinander existieren können, wenn wir den Speicherverbrauch jedes Prozesses halbieren. Wenn wir statt dessen die Speicherbelegungszeit halbieren, dann können die beiden Prozesse nebeneinander existieren, aber nur solange ihre Zeiträume hoher Speicherbelegung nicht überlappen. Demnach ist es besser, die Speicherbelegung zu reduzieren.

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.
de_DE: Unglücklicherweise schränken die Erfordernisse des Programms die Wahl der Optimierung ein. Die Größe der Pixbuf-Daten in <app>Swell Foop</app> ist von der Größe der Grafiken im Spiel abhängig und kann nicht ohne Weiteres reduziert werden. Allerdings kann die Zeit zum Laden des Programms in den Speicher drastisch reduziert werden! Das Bild unten zeigt die <app>Massif</app>-Analyse von <app>Swell Foop</app> nach den Änderungen, die die Pixbufs entsorgen, sobald diese vom X-Server geladen wurden.

note: (itstool) path: figure/title
en: <app>Massif</app> output for the optimized <app>Swell Foop</app> program.
de_DE: <app>Massif</app>-Ausgaben für das optimierte Programm <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-after.png' md5='36d1b4ad7ab49b28b69ad3eabbaa7069'
de_DE: ok

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.
de_DE: Die Raumzeit-Belegung von gdk_pixbuf_new ist nun nur noch ein dünnes Band, das nur kurzzeitig einen Spitzenwert hat (es ist nun das sechzehnte schraffierte magenta Band von oben). Als Bonus ist der Spitzenspeicherverbrauch um 200 kB gesunken, weil die Spitze vor anderen Speicheranforderungen liegt. Wenn zwei solche Prozesse zeitgleich liefen, wäre die Wahrscheinlichkeit ziemlich gering, dass der höchste Speicherverbrauch beider zusammen fällt.

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.
de_DE: Können wir noch zulegen? Eine schnelle Untersuchung der Textausgabe von <app>Massif</app> enthüllt: g_strdup ist der neue Hauptschuldige.

note: (itstool) path: section/p
en: If we look closer though we see that it is called from many, many, places.
de_DE: Bei näherer Betrachtung sehen wir jedoch, dass es von vielen verschiedenen Orten aus aufgerufen wird.

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.
de_DE: Nun begegnen wir geschmälerten Resultaten für unsere Bemühungen. Der Graph deutet einen weiteren möglichen Schritt an: Die Bänder »other« und »heap admin« sind beide ziemlich groß. Dies besagt, dass eine Vielzahl kleiner Anforderungen an vielen Orten gemacht werden. Jene zu eliminieren ist schwierig, aber wenn sie zusammen gelegt werden, dann werden die einzelnen Anforderungen größer und der Verwaltungsaufwand (»heap admin«) kann reduziert werden.

note: (itstool) path: section/title
en: Caveats
de_DE: Vorbehalte

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.
de_DE: Es gibt ein paar Dinge, auf die man achten muss. Erstens: Raumzeit wird nur als Prozentangabe geliefert. Sie müssen mit der Gesamtgröße des Programms vergleichen, um festzustellen, ob es sich lohnt, diese Speichermenge anzugehen. Der Graph mit der vertikalen Achse in Kilobytes eignet sich gut dafür.

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.
de_DE: Zweitens: <app>Massif</app> erfasst nur die Speicherbelegung durch Ihr eigenes Programm. Ressourcen wie Pixmaps werden im X-Server gespeichert und werden nicht durch <app>Massif</app> berücksichtigt. In dem Beispiel mit <app>Swell Foop</app> haben wir tatsächlich nur den Speicherverbrauch von client-seitigen Pixbufs zu server-seitigen Pixmaps verlagert. Obwohl dies nur nach Schummeln aussieht, gab es dennoch Geschwindigkeitsgewinne. Bilddaten im X-Server beschleunigen die Grafik-Routinen und verhindert viele Inter-Prozess-Kommunikation. Ebenso werden die Pixmaps in nativem Grafikformat gespeichert, welches oft kompakter ist als das 32-bit RGBA-Format von gdk_pixbuf. Um den Effekt von Pixmaps und anderen Ressourcen des X-Servers zu messen, sollten Sie das Programm <link href="http://www.freedesktop.org/Software/xrestop">xrestop</link> verwenden.
