[gnome-devel-docs] Add Simplified Chinese optimization guide translation.

[Aron Xu <aronxu src gnome org>]

commit 5734c1abdfad3cf0982afddc021c11b2ef6808aa
Author: YunQiang Su <wzssyqa gmail com>
Date:   Sat Jul 24 17:50:03 2010 +0800

    Add Simplified Chinese optimization guide translation.

 optimization-guide/Makefile.am    |    2 +-
 optimization-guide/zh_CN/zh_CN.po |  921 +++++++++++++++++++++++++++++++++++++
 2 files changed, 922 insertions(+), 1 deletions(-)
---
diff --git a/optimization-guide/Makefile.am b/optimization-guide/Makefile.am
index 680039c..ad3b082 100644
--- a/optimization-guide/Makefile.am
+++ b/optimization-guide/Makefile.am
@@ -2,7 +2,7 @@ include $(top_srcdir)/gnome-doc-utils.make
 dist-hook: doc-dist-hook
 
 DOC_MODULE = optimization-guide
-DOC_LINGUAS = cs de el es
+DOC_LINGUAS = cs de el es zh_CN
 DOC_ENTITIES =
 DOC_INCLUDES = \
   optimization-harmful.xml \
diff --git a/optimization-guide/zh_CN/zh_CN.po b/optimization-guide/zh_CN/zh_CN.po
new file mode 100644
index 0000000..5b83697
--- /dev/null
+++ b/optimization-guide/zh_CN/zh_CN.po
@@ -0,0 +1,921 @@
+# Chinese (China) translation for gnome-devel-docs.
+# Copyright (C) 2010 gnome-devel-docs's COPYRIGHT HOLDER
+# This file is distributed under the same license as the gnome-devel-docs package.
+# YunQiang Su <wzssyqa gmail com>, 2010.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: gnome-devel-docs master\n"
+"POT-Creation-Date: 2010-05-14 17:00+0000\n"
+"PO-Revision-Date: 2010-07-21 14:01+0800\n"
+"Last-Translator: YunQiang Su <wzssyqa gmail com>\n"
+"Language-Team: Chinese (China) <i18n-zh googlegroups com>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: C/optimization-intro.xml:3(title)
+msgid "The Quick Guide to Optimizing GNOME Programs"
+msgstr "ä¼?å??æ??æ¡£ç??å¿«é??æ??å??"
+
+#: C/optimization-intro.xml:5(para)
+msgid ""
+"This is a brief introduction to optimization, both the hows and the whys. "
+"Details of individual tools and techniques are left for later articles, but "
+"a collection of hints and tricks is provided."
+msgstr ""
+"è¿?æ?¯å?³äº?ä¼?å??ç??ä¸?个ç®?å??ä»?ç»?ï¼?以å??å¦?ä½?å??å??为ä½?è¿?ä¹?å??ã??æ¯?个工å?·å??æ??æ?¯ç??ç»?è??ç??å?°"
+"æ?ªæ?¥ç??æ??档中ï¼?ä½?æ?¯æ??ä¾?äº?ä¸?äº?æ??示å??æ??å·§ã??"
+
+#: C/optimization-intro.xml:10(title)
+msgid "What are we Optimizing?"
+msgstr "ä»?ä¹?é??è¦?ä¼?å??ï¼?"
+
+#: C/optimization-intro.xml:11(para)
+msgid ""
+"When we optimize for GNOME the first thing to remember is this: we are not "
+"trying to make the program better, we are trying to make the person using "
+"the computer happier."
+msgstr ""
+"ä¼?å?? GNOME ç¨?åº?æ?¶é??è¦?è®°ä½?ç??第ä¸?件äº?æ??æ?¯ï¼?æ??们å?¨å??ç??ä¸?æ?¯ä½¿ç¨?åº?æ?´å¥½ï¼?è??æ?¯è®©äººä»¬"
+"æ?´å¿«ä¹?å?°ä½¿ç?¨è®¡ç®?æ?ºã??"
+
+#: C/optimization-intro.xml:14(para)
+msgid ""
+"Better programs make people happier, but there are some improvements that "
+"will make them a lot happier than others: Responsiveness, start-up time, "
+"easy to access commands and not having the computer go into swap the moment "
+"more than two programs are open."
+msgstr ""
+"æ?´å¥½ç??ç¨?åº?å?¯ä»¥ä½¿äººä»¬æ?´å¿«ä¹?ï¼?ä½?æ?¯ä¸?äº?æ?¹è¿?å°?使ä»?们æ¯?å?«äººæ?´å¿«ä¹?ï¼?å??åº?é??度ã??å?¯å?¨"
+"æ?¶é?´ã??æ?´å®¹æ??æ?¾å?°å?½ä»¤ä»¥å??å?¨å¤?个ç¨?åº?å??æ?¶æ??å¼?æ?¶ä¸?让计ç®?æ?ºå?¡ä½?ã??"
+
+#: C/optimization-intro.xml:17(para)
+#, fuzzy
+msgid ""
+"Traditional optimization tackles concepts like CPU use, code size, the "
+"number of mouse clicks and the memory use of the program. This second list "
+"has been chosen to correlate with the first list, however there is an "
+"important difference: The person using GNOME doesn't care about the second "
+"list, but they care a lot about the first list. When optimizing GNOME "
+"programs we will reduce CPU use, memory use and all those things, but these "
+"are the means to the end, not the final goal. We are optimizing for people."
+msgstr "ä¼ ç»?ç??ä¼?å??解å?³ CPU 使ç?¨ã??代ç ?大å°?ã??é¼ æ ?ç?¹å?»é??以å??å??å­?使ç?¨ã??"
+
+#: C/optimization-intro.xml:23(title)
+msgid "Doing the Optimization"
+msgstr "è¿?è¡?ä¼?å??"
+
+#: C/optimization-intro.xml:24(para)
+msgid ""
+"The previous section omitted one important qualifier: To optimize something "
+"it has to be measurable. You can't measure happiness. However, you can "
+"measure start-up time so you can tell if you have improved it. Happiness "
+"will then, hopefully, follow."
+msgstr ""
+"ä¸?é?¢ç??ç« è??忽ç?¥äº?ä¸?个é??è¦?ç??æ??æ ?ï¼?ä¼?å??ç??ä¸?西å¿?é¡»æ?¯å?¯é??æµ?ç??ã??å¿«ä¹?æ?¯æ? æ³?é??æµ?ç??ï¼?"
+"ä½?æ?¯å?¯ä»¥é??æµ?å?¯å?¨æ?¶é?´ï¼?ç?¶å??讨论æ?¯å?¦é??è¦?对å?¶è¿?è¡?ä¼?å??ã??å¸?æ??å¿«ä¹?ä¹?è?½é??ä¹?è??æ?¥å?§ã??"
+
+#: C/optimization-intro.xml:27(para)
+msgid ""
+"Optimization is the process of measurement, refinement and re-measurement. "
+"So the first thing you must do is find a way to measure what you are "
+"optimizing. Ideally this measurement is a single number, for example: the "
+"time taken to perform a task. This is your benchmark, it is the only way to "
+"tell if you are winning or losing. There is a big difference between a "
+"program that <emphasis>should</emphasis> be fast and a program that "
+"<emphasis>is</emphasis> fast."
+msgstr ""
+"ä¼?å??æ?¯æµ?é??ã??ç²¾ç??æ±?ç²¾å??é??æ?°æµ?é??ç??è¿?ç¨?ã??æ??以ï¼?第ä¸?件å¿?é¡»è¦?å??ç??äº?æ??å°±æ?¯æ?¾å?°ä¸?ç§?"
+"æµ?é??è¦?ä¼?å??ç??äº?æ??ç??æ?¹æ³?ã??è¿?个æµ?é??ç»?æ??æ??好æ?¯ä¸?个æ?°å­?ï¼?ä¾?å¦?ï¼?æ?§è¡?ä¸?个任å?¡æ??é??è¦?"
+"ç??æ?¶é?´ã??è¿?æ?¯æ?¨ç??æ?§è?½æµ?è¯?ï¼?è¿?æ?¶å?¯ä¸?å?¯ä»¥å??è¯?æ?¨é??è¿?è¿?æ?¯å¤±è´¥ç??æ?¹æ³?ã??å?¨ä¸?个ç¨?åº? "
+"<emphasis>åº?该</emphasis> å¿«è¿?æ?¯ <emphasis>å·²ç»?</emphasis> å¿«ä¹?é?´ç??å?ºå?«ã??"
+
+#: C/optimization-intro.xml:30(para)
+msgid ""
+"Once you have a basic benchmark you need to find out why your code is not "
+"doing as well as it should. It is tempting to do this by inspection: just "
+"looking at the code and trying to spot something that looks like it needs "
+"improvement. You will invariably be wrong. Using a profiler to get a "
+"detailed break-down of what your program really does is the only way to be "
+"sure."
+msgstr ""
+"è¿?è¡?äº?å?ºæ?¬ç??æ?§è?½æµ?è¯?ä¹?å??ï¼?æ?¨é??è¦?æ?¾å?ºä¸ºä»?ä¹?代ç ?没æ??å¦?å?¶åº?该ç??é?£æ ·å¿«ã??å?¯ä»¥é??è¿?"
+"è¿?æ ·æ?¥å°?è¯?ï¼?æ£?æ?¥ä»£ç ?æ?¾å?ºé??è¦?æ?¹è¿?ç??å?°æ?¹ã??æ?¨å?¯è?½æ?»ä¼?æ?¯é??误ç??ã??使ç?¨ä¸?个æ?§è?½å??æ??"
+"å?¨æ?¥è?·å??详ç»?ç??ç¨?åº?æ¯?æ­¥ç??å·¥ä½?æ?¯å?¯ä¸?å?¯ä»¥ä¿?è¯?æ?¯æ­£ç¡®ç??æ?¹æ³?ã??"
+
+#: C/optimization-intro.xml:33(para)
+msgid ""
+"Usually the problem is isolated to small sections of code. Pick the worst "
+"place and concentrate on that first. Once that is done, rerun the profiler "
+"and repeat. As you proceed the gains made at each step will get less and "
+"less, at some point you will have to decide that the results are good "
+"enough. If your efforts are only extracting 10% improvements then you are "
+"well past the point where you should have stopped."
+msgstr ""
+"ç¨?åº?é??常å?¯ä»¥å??为å¾?å°?ç??代ç ?å??ã??æ?¾å?ºæ?§è?½æ??å·®ç??å?°æ?¹å¹¶é??中精å??é¦?å??å¤?ç??ã??å®?æ??ä¹?"
+"å??ï¼?é??æ?°è¿?è¡?æ?§è?½å??æ??å?¨ç?¶å??é??å¤?ã??æ¯?è¿?è¡?ä¸?次è¿?æ ·ç??å?ªå??å°?è?·å¾?ç??è¶?æ?¥è¶?å°?ï¼?æ?¨å?¯ä»¥"
+"å?¨ä¸?个ç?¹ä¸?认为ç»?æ??å·²ç»?足å¤?好äº?ã??å¦?æ??æ?¨ç??å?ªå??å?ªè?½è?·å?? 10% ç??æ?¹è¿?ï¼?æ??好ç?¥è¿?è¿?个"
+"ç?¹ï¼?并ä¸?åº?该å??æ­¢ã??"
+
+#: C/optimization-intro.xml:36(para)
+msgid ""
+"Don't forget the big picture. For example, rather than just trying to speed "
+"up a piece of code, ask yourself if it needs to be run at all. Could it be "
+"combined with another piece of code? Can the results of previous "
+"calculations be saved and reused? It won't even need to be optimized if it "
+"is in a place where the user is never going to notice it. Worse still, the "
+"code may already be optimized and is doing the heavy calculations now to "
+"avoid doing them later. Code does not run in isolation and neither does the "
+"optimization process."
+msgstr ""
+"ä¸?è¦?å¿?记大å?¾ç??ã??ä¾?å¦?ï¼?å?¨å°?è¯?å? é??ä¸?段代ç ?ä¹?å??ï¼?å??æ?³æ?³æ?¯å?¦ç??ç??é??è¦?å®?ã??æ?¯å?¦å?¯ä»¥"
+"å??å?¶å®?代ç ?å??ç»?å??ï¼?å??é?¢è®¡ç®?ç??ç»?æ??æ?¯å?¦å?¯ä»¥ä¿?å­?èµ·æ?¥å¹¶é??ç?¨ï¼?å¦?æ??æ?¯ç?¨æ?·æ ¹æ?¬ä¸?ä¼?注"
+"æ??ç??å?°æ?¹å°±ç??è?³ä¸?é??è¦?ä¼?å??ã??æ?´ç³?ç??æ?¯ï¼?代ç ?å·²ç»?ä¼?å??äº?ï¼?并ä¸?æ­£å?¨è¿?è¡?é«?è´?è½½è¿?ç®?ï¼?"
+"é?£å°±é??è¦?é?¿å??ç¨?å??å??次è¿?è¡?è¿?ç®?ã??ä¸?å­¤ç«?è¿?è¡?ç??代ç ?ä¹?ä¸?é??è¦?ä¼?å??è¿?ç¨?ã??"
+
+#: C/optimization-intro.xml:41(title)
+msgid "Hints"
+msgstr "æ??示"
+
+#: C/optimization-intro.xml:43(title)
+msgid "The Fundamentals"
+msgstr "å?ºæ?¬å??ç??"
+
+#: C/optimization-intro.xml:45(para)
+msgid ""
+"Re-run your benchmark after every change you make to the code and keep a log "
+"of everything you change and how it affects the benchmark. This lets you "
+"undo mistakes and also helps you not to repeat mistakes."
+msgstr ""
+"对代ç ?è¿?è¡?æ?´æ?¹ä¹?å??é??æ?°è¿?è¡?æ?§è?½æµ?è¯?ï¼?è®°å½?æ¯?次ç??æ?´æ?¹å??对æ?§è?½ç??å½±å??ã??è¿?å?¯ä»¥å¸®å?©"
+"æ?¨ä¿®å¤?é??误ï¼?ä¹?å?¯ä»¥å¸®æ?¨é?¿å??é??å¤?ç?¯é??ã??"
+
+#: C/optimization-intro.xml:50(para)
+msgid ""
+"Make sure your code is correct and bug-free before optimizing it. Check that "
+"it remains correct and bug-free after optimization."
+msgstr ""
+"å?¨è¿?è¡?ä¼?å??ä¹?å??ç¡®ä¿?代ç ?æ?¯æ­£ç¡®ä¸?没æ??缺é?·ç??ã??å?¨ä¼?å??ä¹?å??æ£?æ?¥æ?¯å?¦ä»?ç?¶æ?¯æ­£ç¡®ä¸?没æ??"
+"缺é?·ç??ã??"
+
+#: C/optimization-intro.xml:55(para)
+msgid "Optimize at the high level before optimizing the details."
+msgstr "å?¨å¯¹ç»?è??è¿?è¡?ä¼?å??ä¹?å??å??å?¨é«?å±?è¿?è¡?ä¼?å??ã??"
+
+#: C/optimization-intro.xml:60(para)
+msgid ""
+"Use the right algorithm. The classic text-book example is using quick-sort "
+"instead of bubble-sort. There are many others, some save memory, some save "
+"CPU. Also, see what shortcuts you can make: you can do quicker than quick-"
+"sort if you are prepared to make some compromises."
+msgstr ""
+"使ç?¨æ­£ç¡®ç??ç®?æ³?ã??ç»?å?¸ç??æ??æ?¬æ??åº?使ç?¨ç??æ?¯å¿«é??æ??åº?è??ä¸?æ?¯å??泡æ??åº?ã??è¿?æ??å¾?å¤?å?¶å®?ï¼?"
+"ä¸?äº?å?¯ä»¥è??ç??å??å­?ï¼?ä¸?äº?å?¯ä»¥è??ç?? CPUã??å??æ ·ï¼?寻æ?¾æ?¨å?¯ä»¥èµ°ç??æ?·å¾?ï¼?å¦?æ??æ?¿æ??è¿?è¡?æ??"
+"äº?ç»?å??ï¼?ç??è?³å?¯ä»¥æ¯?å¿«é??æ??åº?æ?´å¿«ã??"
+
+#: C/optimization-intro.xml:65(para)
+msgid ""
+"Optimization is a trade-off. Caching results speeds up calculations, but "
+"increases memory use. Saving data to disk saves memory, but costs time when "
+"it is loaded back from disk."
+msgstr ""
+"ä¼?å??å°±æ?¯æ??è¡·ã??ç¼?å­?ç»?æ??å?¯ä»¥å? é??è¿?è¡?ï¼?ä½?æ?¯ä¼?å¢?å? å??å­?使ç?¨ã??å°?æ?°æ?®ä¿?å­?å?°ç£?ç??å?¯ä»¥"
+"è??ç??å??å­?ï¼?ä½?ä»?ç£?ç??中å? è½½æ?¶æµªè´¹æ?¶é?´ã??"
+
+#: C/optimization-intro.xml:70(para)
+#, fuzzy
+msgid ""
+"Make sure you choose a wide variety of inputs to optimize against. If you "
+"don't it is easy to end up with a piece of code carefully optimized for one "
+"file and no others."
+msgstr "ç¡®ä¿?é??æ?©äº?足å¤?å¤?ç??è¾?å?¥æ?¥å??次è¿?è¡?ä¼?å??ã??å¦?æ??ä¸?è?½å®¹æ??"
+
+#: C/optimization-intro.xml:75(para)
+msgid ""
+"Avoid expensive operations: Multiple small disk reads. Using up lots of "
+"memory so disk swapping becomes necessary. Avoid anything that writes or "
+"reads from the hard disk unnecessarily. The network is slow too. Also avoid "
+"graphics operations that need a response from the X server."
+msgstr ""
+"é?¿å??é«?æ¶?è??ç??æ??ä½?ï¼?å¤?次ä»?ç£?ç??读å??å¾?å°?ç??æ?°æ?®ã??使ç?¨å¾?å¤?å??å­?ä¼?é??è¦?交æ?¢ã??é?¿å??ä»»ä½?"
+"ä¸?é??è¦?ç??硬ç??读å??ã??ç½?ç»?ä¹?æ?¯å¾?æ?¢ç??ã??å??æ ·é?¿å??é??è¦? X æ??å?¡å?¨å??åº?ç??å?¾å½¢æ??ä½?ã??"
+
+#: C/optimization-intro.xml:81(title)
+msgid "Traps for the Unwary"
+msgstr "ç²?å¿?é? æ??ç??é?·é?±"
+
+#: C/optimization-intro.xml:83(para)
+msgid ""
+"Beware of side effects. There can often be strange interactions between "
+"different sections of code, a speed-up in one part can slow another part "
+"down."
+msgstr ""
+"注æ??å?¯ä½?ç?¨ã??å?¨ä¸?å??ç??代ç ?é?¨å??ä¹?é?´ç»?常æ??å¥?æ?ªç??交äº?ï¼?å? é??ä¸?个é?¨å??å?¯è?½ä¼?使å?¦ä¸?é?¨"
+"å??ç??é??度é??ä½?ã??"
+
+#: C/optimization-intro.xml:88(para)
+msgid ""
+"When timing code, even on a quiet system, events outside the program add "
+"noise to the timing results. Average over multiple runs. If the code is very "
+"short, timer resolution is also a problem. In this case measure the time the "
+"computer takes to run the code 100 or 1000 times. If the times you are "
+"recording are longer than a few seconds, you should be OK."
+msgstr ""
+"æµ?é??代ç ?ç??è¿?è¡?æ?¶é?´æ?¶ï¼?å?³ä½¿å?¨å®?é??ç??ç³»ç»?ä¸?ï¼?ç¨?åº?ä¹?å¤?ç??äº?件ä¹?ä¼?对计æ?¶äº§ç??å½±å??ã??"
+"å¤?次è¿?è¡?å??å¹³å??å?¼ã??å¦?æ??代ç ?é??常ç?­ï¼?计æ?¶ç²¾åº¦ä¹?æ?¯ä¸?个é?®é¢?ã??è¿?æ?¶ï¼?æµ?é??代ç ?è¿?è¡? "
+"100 ç??è?³ 1000 次ç??æ?¶é?´ã??å¦?æ??æ?¨è®°å½?ç??æ?¶é?´é?¿è¾¾æ?°ç§?ï¼?å°±å?¯ä»¥äº?ã??"
+
+#: C/optimization-intro.xml:93(para)
+msgid ""
+"It is very easy to be misled by the profiler. There are stories of people "
+"optimizing the operating system idle-loop because that is where it spent all "
+"its time! Don't optimize code that does nothing the user cares about."
+msgstr ""
+"ä¹?å¾?容æ??被æ?§è?½å??æ??å?¨è¯¯å¯¼ã??æ??人æ?¾ç»?ä¼?å??æ??äº?æ??ä½?ç³»ç»?ç?? idle-loopï¼?å? 为å®?è??è´¹æ??"
+"äº?ç³»ç»?æ??æ??ç??æ?¶é?´ã??ä¸?è¦?ä¼?å??å??ç?¨æ?·æ ¹æ?¬ä¸?å?³å¿?ç??é?¨å??ã??"
+
+#: C/optimization-intro.xml:98(para)
+msgid ""
+"Remember the resources on the X server. Your program's memory usage doesn't "
+"include the pixmaps that are stored in the X server's process, but they are "
+"still using up memory. Use xrestop to see what resources your program is "
+"using."
+msgstr ""
+"å?«å¿?è®°äº? X æ??å?¡å?¨ä¸?ç??æ?¶é?´ã??æ?¨ç??ç¨?åº?ç??å??å­?使ç?¨é??并没æ??å??å?«å?¨ X æ??å?¡å?¨è¿?ç¨?中å­?"
+"å?¨ç??å??ç´ å½±å°?ï¼?ä½?å®?们ä»?ç?¶ä½¿ç?¨å??å­?ã??使ç?¨ xrestop æ?¥ç??æ?¨ç??ç¨?åº?使ç?¨ç??èµ?æº?ã??"
+
+#: C/optimization-intro.xml:104(title)
+msgid "Low Level Hints"
+msgstr "åº?å±?æ??示"
+
+#: C/optimization-intro.xml:106(para)
+msgid ""
+"When optimizing memory use, be wary of the difference between peak usage and "
+"average memory usage. Some memory is almost always allocated, this is "
+"usually bad. Some is only briefly allocated, this may be quite acceptable. "
+"Tools like massif use the concept of space-time, the product of memory used "
+"and the duration it was allocated for, instead."
+msgstr ""
+"ä¼?å??å??å­?使ç?¨æ?¶ï¼?è­¦æ??é«?峰使ç?¨é??å??å¹³å??使ç?¨é??ç??å?ºå?«ã??æ?»æ?¯æ??æ??ç?³è¯·ç??å??å­?æ?¯ä¸?好"
+"ç??ã??ä¸?äº?ä»?ä»?æ?¯ç®?å??ç??ç?³è¯·ï¼?è¿?æ?¯å?¯ä»¥æ?¥å??ç??ã??类似äº? massif ç??å·¥å?·ä½¿ç?¨æ?¶ç©º (å??å­?"
+"使ç?¨é??å??使ç?¨æ?¶é?´ç??ä¹?积) ç??æ¦?念æ?¥ä»£æ?¿ã??"
+
+#: C/optimization-intro.xml:111(para)
+msgid ""
+"Time simplified bits of code that do only the things you know are essential, "
+"this gives an absolute lower limit on the time your code will take. For "
+"example, when optimizing a loop time the empty loop. If that is still too "
+"long no amount of micro-optimization will help and you will have to change "
+"your design. Make sure the compiler doesn't optimize away your empty loop."
+msgstr ""
+
+#: C/optimization-intro.xml:116(para)
+#, fuzzy
+msgid ""
+"Move code out from inside loops. A slightly more complicated piece of code "
+"that is executed once is far quicker than a simple piece of code executed a "
+"thousand times. Avoid calling slow code often."
+msgstr "å?»é?¤å??é?¨å¾ªç?¯ç??代ç ?ã??"
+
+#: C/optimization-intro.xml:121(para)
+msgid ""
+"Give the compiler as many hints as possible. Use the const keyword. Use "
+"<envar>G_INLINE_FUNC</envar> for short, frequently called, functions. Look "
+"up <envar>G_GNUC_PURE</envar>, <envar>G_LIKELY</envar> and the other glib "
+"miscellaneous macros. Use the macros instead of gcc-specific keywords to "
+"ensure portability."
+msgstr ""
+"ç»?ç¼?è¯?å?¨å°½å?¯è?½å¤?ç??æ??示ã??使ç?¨å¸¸é??å?³é?®å­?ã??使ç?¨ <envar>G_INLINE_FUNC</envar> ä½?"
+"为ç»?常è°?ç?¨ç??å?½æ?°ç??ç®?称ã??æ?¥ç?? <envar>G_GNUC_PURE</envar>ï¼?<envar>G_LIKELY</"
+"envar> å??å?¶å®? glib æ??项å®?ã??使ç?¨è¿?äº?å®?代æ?¿ gcc ä¸?ç?¨ç??å?³é?®å­?ï¼?以确ä¿?å?¯ç§»æ¤?æ?§ã??"
+
+#: C/optimization-intro.xml:126(para)
+msgid ""
+"Don't use assembly language. It is not portable and, while it may be fast on "
+"one processor, it is not even guaranteed to be fast on every processor that "
+"supports that architecture (e.g. Athlon vs. Pentium 4)."
+msgstr ""
+"ä¸?è¦?使ç?¨æ±?ç¼?语è¨?ã??æ±?ç¼?语è¨?ä¸?å?¯ç§»æ¤?ï¼?è??ä¸?è?½ç?¶å?¯è?½å?¨ä¸?个å¤?ç??å?¨ä¸?å¾?å¿«ï¼?ä½?æ?¯ç??è?³"
+"å?¨æ?¯æ??å??æ ·å¤?ç??å?¨æ?¶æ??ç??å¤?ç??å?¨ä¸?ä¹?ä¸?è?½ä¿?è¯?å?¯ä»¥å¾?å¿« (ä¾?å¦?é??é¾?å??å¥?å??ç??å?ºå?«)ã??"
+
+#: C/optimization-intro.xml:131(para)
+msgid ""
+"Don't rewrite an existing library routine unless you are sure it is "
+"unnecessarily slow. Many CPU-intensive library routines have already been "
+"optimized. Conversely, some library routines are slow, especially ones that "
+"make system calls to the operating system."
+msgstr ""
+"ä¸?è¦?é??å??å·²æ??ç??åº?å?½æ?°ï¼?é?¤é??ç¡®å®?åº?å?½æ?°ä¸?å?¯æ?¥å??å¾?æ?¢ã??å¾?å¤? CPU æ??æ??ç??åº?å?½æ?°é?½æ?¯ä¼?"
+"å??è¿?ç??ã??ç?¸å??å?°ï¼?ä¸?äº?åº?å?½æ?°ä¹?æ?¯æ?¢ç??ï¼?å°¤å?¶æ?¯é?£äº?使ç?¨ç³»ç»?è°?ç?¨ç??ã??"
+
+#: C/optimization-intro.xml:136(para)
+msgid ""
+"Minimize the number of libraries you link to. The fewer libraries to link "
+"in, the faster the program starts. This is a difficult thing to do with "
+"GNOME."
+msgstr "使ç?¨å°½é??å°?ç??åº?ã??é?¾æ?¥å?°ç??åº?è¶?å°?ï¼?ç¨?åº?å?¯å?¨è¶?å¿«ã??对äº? GNOMEï¼?è¿?å¾?é?¾è¾¾å?°ã??"
+
+#: C/optimization-intro.xml:142(title)
+msgid "High Level Tricks"
+msgstr "é«?å±?æ??å·§"
+
+#: C/optimization-intro.xml:144(para)
+msgid ""
+"Take advantage of concurrency. This doesn't just mean using multiple "
+"processors, it also means taking advantage of the time the user spends "
+"thinking about what they are going to do next to perform some calculations "
+"in anticipation. Do calculations while waiting for data to be loaded off "
+"disk. Take advantage of multiple resources, use them all at once."
+msgstr ""
+"å??æ?¥å¹¶å??ç??ä¼?å?¿ã??è¿?并ä¸?ä»?ä»?æ??å?³ç??使ç?¨å¤?å¤?ç??å?¨ï¼?ä¹?æ??å?³ç??å??å°?ç?¨æ?·æ?§è¡?ä¸?äº?计ç®?æ??"
+"é¢?æ??ç??æ?¶é?´ã??å?¨ç­?å¾?ä»?ç£?ç??ä¸?å? è½½æ?°æ?®æ?¯è¿?è¡?计ç®?ã??å??å??使ç?¨å¤?ç§?èµ?æº?ï¼?å??æ?¶ä½¿ç?¨å®?"
+"们ã??"
+
+#: C/optimization-intro.xml:149(para)
+msgid ""
+"Cheat. The user only has to think that the computer is fast, it doesn't "
+"matter whether it actually is or not. It is the time between the command and "
+"the answer that is important, it doesn't matter if the response is pre-"
+"calculated, cached, or will in fact be worked out later at a more convenient "
+"time, as long as the user gets what they expect."
+msgstr ""
+"欺éª?ã??ç?¨æ?·ä»?ä»?认为计ç®?æ?ºå¾?å¿«ï¼?è??ä¸?管å®?é??ä¸?æ?¯å?¦å¦?æ­¤ã??å?½ä»¤å??ç»?æ??ä¹?é?´ç??æ?¶é?´å¾?é??"
+"è¦?ï¼?è??æ? 论æ?¯æ??å??计ç®?ç??ã??ç¼?å­?ç??è¿?æ?¯å?¨ç¨?å??æ?¹ä¾¿ç??æ?¶é?´è¿?è¡?å®?é??计ç®?ï¼?尽快å?°ç»?å?ºç?¨"
+"æ?·æ??æ??ç??ç»?æ??ã??"
+
+#: C/optimization-intro.xml:154(para)
+msgid ""
+"Do things in the idle loop. It is easier to program than using full multi-"
+"threading but still gets things done out of the users eye. Be careful "
+"though, if you spend too long in the idle loop your program will become "
+"sluggish. So regularly give control back to the main loop."
+msgstr ""
+"å?¨ç©ºé?²å¾ªç?¯ä¸­è¿?è¡?æ??äº?å·¥ä½?ã??è¿?æ¯?å¤?线ç¨?æ?´å®¹æ??ç¼?ç¨?ä½?ä»?ç?¶å?¨ç?¨æ?·è§?线ä¹?å¤?è¿?è¡?äº?å·¥"
+"ä½?ã??ä»?ç?¶é??è¦?注æ??ï¼?å¦?æ??å?¨ç©ºé?²å¾ªç?¯ä¸­è?±è´¹å¤ªå¤?æ?¶é?´ï¼?ç¨?åº?å°?å??å?¡ã??æ??以é??è¦?ç»?常è¿?å??"
+"主循ç?¯ã??"
+
+#: C/optimization-intro.xml:159(para)
+msgid ""
+"If all else fails, tell the user that the code is going to be slow and put "
+"up a progress bar. They won't be as happy as if you had just presented the "
+"results, but they will at least know the program hasn't crashed and they can "
+"go get a cup of coffee."
+msgstr ""
+"å¦?æ??é?½å¤±è´¥äº?ï¼?å??è¯?ç?¨æ?·ä»£ç ?å°?ä¼?æ¯?è¾?æ?¢å¹¶ä¸?使ç?¨è¿?度æ?¡ã??å¦?æ??ä»?ä»?ç»?å?ºç»?æ??ï¼?ç?¨æ?·å¹¶"
+"ä¸?ä¼?é«?å?´ï¼?ä»?们è?³å°?ä¼?ç?¥é??ç¨?åº?没æ??å´©æº?ï¼?ä»?们å?¯ä»¥å?»å??æ?¯å??å?¡ã??"
+
+#. When image changes, this message will be marked fuzzy or untranslated for you.
+#. It doesn't matter what you translate it to: it's not used at all.
+#: C/optimization-massif.xml:52(None)
+msgid ""
+"@@image: 'figures/massif-before.png'; md5=1a6b2ace548e6789ab8bfacb3727b345"
+msgstr ""
+"@@image: 'figures/massif-before.png'; md5=1a6b2ace548e6789ab8bfacb3727b345"
+
+#. When image changes, this message will be marked fuzzy or untranslated for you.
+#. It doesn't matter what you translate it to: it's not used at all.
+#: C/optimization-massif.xml:114(None)
+msgid ""
+"@@image: 'figures/massif-after.png'; md5=36d1b4ad7ab49b28b69ad3eabbaa7069"
+msgstr ""
+"@@image: 'figures/massif-after.png'; md5=36d1b4ad7ab49b28b69ad3eabbaa7069"
+
+#: C/optimization-massif.xml:3(title)
+msgid ""
+"Using <application>Massif</application> for Profiling Memory Use in GNOME "
+"Software"
+msgstr "使ç?¨ <application>Massif</application> å??æ?? GNOME 软件ç??å??å­?使ç?¨"
+
+#: C/optimization-massif.xml:5(para)
+msgid ""
+"This article describes how to use the <application>Massif</application> heap "
+"profiler with GNOME applications. We describe how to invoke, interpret, and "
+"act on the output of <application>Massif</application>. The "
+"<application>Same GNOME</application> game is used as an example."
+msgstr ""
+"è¿?ç¯?æ??ç« æ??è¿°æ??æ ·å?¨ GNOME ç¨?åº?中使ç?¨ <application>Massif</application> å ?å??æ??"
+"å?¨ï¼?解é??æ??æ ·è°?ç?¨ã??ç??解已ç»?对 <application>Massif</application> ç??è¾?å?ºè¿?è¡?æ??"
+"ä½?ã??"
+
+#: C/optimization-massif.xml:10(title)
+msgid "Introduction"
+msgstr "ç®?ä»?"
+
+#: C/optimization-massif.xml:11(para)
+msgid ""
+"<application>Massif</application> is a member of the <ulink type=\"http\" "
+"url=\"http://valgrind.org/\";>valgrind</ulink> suite of memory-profiling "
+"tools. Its purpose is to give a detailed view of dynamic memory usage during "
+"the lifetime of the program. Specifically it records the memory use of the "
+"heap and the stack."
+msgstr ""
+"<application>Massif</application> æ?¯ <ulink type=\"http\" url=\"http://";
+"valgrind.org/\">valgrind</ulink> å??å­?å??æ??å¥?件ç??ä¸?个æ??å??ã??å®?ç??ç?®ç??æ?¯å?¨ç¨?åº?ç??ç??"
+"å?½æ??é??ç»?å?ºå?¨æ??å??å­?使ç?¨ç??ç»?è??ã??å®?ä¼?ä¸?é?¨è®°å½?å ?æ ?ç??å??å­?使ç?¨ã??"
+
+#: C/optimization-massif.xml:14(para)
+msgid ""
+"The heap is the region of memory which is allocated with functions like "
+"malloc. It grows on demand and is usually the largest region of memory in a "
+"program. The stack is where all the local data for functions is stored. This "
+"includes the \"automatic\" variables in C and the return address for "
+"subroutines. The stack is typically a lot smaller and a lot more active than "
+"the heap. We won't consider the stack explicitly since <application>Massif</"
+"application> treats it as though it were just another part of the heap. "
+"<application>Massif</application> also gives information about how much "
+"memory is used to manage the heap."
+msgstr ""
+"å ?æ?¯ä½¿ç?¨ç±»ä¼¼äº? malloc ç??å?½æ?°å??é??å??å­?ç??å?°æ?¹ã??å®?æ ¹æ?®é??è¦?å¢?é?¿ï¼?è??ä¸?é??常æ?¯ç¨?åº?中"
+"æ??大ç??å??å­?å?ºå??ã??æ ?æ?¯å­?æ?¾å?½æ?°ç??æ?¬å?°æ?°æ?®ç??å?°æ?¹ï¼?å??æ?¬ C 语è¨?中ç??è?ªå?¨å??é??å??å­?å?½æ?°"
+"ç??è¿?å??å?°å??ã??æ ?é??常æ¯?å ?æ?´å°?æ?´æ´»è·?ã??æ??们并没æ??æ?¾å¼?å?°è??è??æ ?ï¼?å? 为 "
+"<application>Massif</application> å°?å?¶è®¤å®?为å ?ç??å?¦å¤?ä¸?é?¨å??ã??"
+"<application>Massif</application> ä¹?ç»?å?ºç®¡ç??å ?æ??使ç?¨ç??å??å­?é??ã??"
+
+#: C/optimization-massif.xml:17(para)
+msgid ""
+"<application>Massif</application> produces two output files: a graphical "
+"overview in a postscript file and a detailed breakdown in a text file."
+msgstr ""
+"<application>Massif</application> 产ç??两个è¾?å?ºæ??件ï¼?ä¸?个 postscript æ ¼å¼?ç??æ¦?"
+"å?µä»¥å??ä¸?个æ??æ?¬æ ¼å¼?ç??ç»?è??详述ã??"
+
+#: C/optimization-massif.xml:22(title)
+msgid "Using <application>Massif</application> with GNOME"
+msgstr "� GNOME 中使� <application>Massif</application>"
+
+#: C/optimization-massif.xml:23(para)
+msgid ""
+"<application>Massif</application> has very few options and for many programs "
+"does not need them. However for GNOME applications, where memory allocation "
+"might be buried deep in either glib or GTK, the number of levels down the "
+"call-stack Massif descends needs to be increased. This is achieved using the "
+"--depth parameter. By default this is 3; increasing it to 5 will guarantee "
+"the call-stack reaches down to your code. One or two more levels may also be "
+"desirable to provide your code with some context. Since the level of detail "
+"becomes quickly overwhelming it is best to start with the smaller depth "
+"parameter and only increase it when it becomes apparent that it isn't "
+"sufficient."
+msgstr ""
+
+#: C/optimization-massif.xml:26(para)
+msgid ""
+"It is also useful to tell <application>Massif</application> which functions "
+"allocate memory in glib. It removes an unnecessary layer of function calls "
+"from the reports and gives you a clearer idea of what code is allocating "
+"memory. The allocating functions in glib are g_malloc, g_malloc0, g_realloc, "
+"g_try_malloc, and g_mem_chunk_alloc. You use the --alloc-fn option to tell "
+"Masiff about them."
+msgstr ""
+
+#: C/optimization-massif.xml:29(para)
+msgid "Your command-line should therefore look something like:"
+msgstr "å? æ­¤ï¼?æ?¨ç??å?½ä»¤è¡?åº?该类似äº?ï¼?"
+
+#: C/optimization-massif.xml:32(programlisting)
+#, no-wrap
+msgid ""
+"\n"
+"valgrind --tool=massif --depth=5  --alloc-fn=g_malloc --alloc-fn=g_realloc --alloc-fn=g_try_malloc \\\n"
+"         --alloc-fn=g_malloc0 --alloc-fn=g_mem_chunk_alloc same-gnome\n"
+"        "
+msgstr ""
+"\n"
+"valgrind --tool=massif --depth=5  --alloc-fn=g_malloc --alloc-fn=g_realloc --alloc-fn=g_try_malloc \\\n"
+"         --alloc-fn=g_malloc0 --alloc-fn=g_mem_chunk_alloc same-gnome\n"
+"        "
+
+#: C/optimization-massif.xml:36(para)
+msgid ""
+"<application>Same GNOME</application> is the program we will be using as an "
+"example. Be warned that, since valgrind emulates the CPU, it will run "
+"<emphasis>very</emphasis> slowly. You will also need a lot of memory."
+msgstr ""
+"<application>Same GNOME</application> æ?¯æ??们ç?¨æ?¥ä½?为è??ä¾?ç??ç¨?åº?ã??å¿?é¡»è¦?è­¦å??ï¼?"
+"å? 为 valgrind 仿ç?? CPUï¼?å®?è¿?è¡?å¾?å°?ä¼?<emphasis>é??常</emphasis> æ?¢ï¼?å??æ?¶ä¹?é??è¦?"
+"å¾?å¤?å??å­?ã??"
+
+#: C/optimization-massif.xml:41(title)
+msgid "Interpreting the Results"
+msgstr "对ç»?æ??ç??解é??"
+
+#: C/optimization-massif.xml:42(para)
+#, fuzzy
+msgid ""
+"The graphical output of <application>Massif</application> is largely self "
+"explanatory. Each band represents the memory allocated by one function over "
+"time. Once you identify which bands are using the most memory, usually the "
+"big thick ones at the top you will have to consult the text file for the "
+"details."
+msgstr "<application>Massif</application> ç??è¾?å?ºå¾?大ç¨?度ä¸?æ?¯è?ªè§£é??ç??ã??"
+
+#: C/optimization-massif.xml:45(para)
+msgid ""
+"The text file is arranged as a hierarchy of sections, at the top is a list "
+"of the worst memory users arranged in order of decreasing spacetime. Below "
+"this are further sections, each breaking the results down into finer detail "
+"as you proceed down the call-stack. To illustrate this we will use the "
+"output of the command above."
+msgstr ""
+
+#: C/optimization-massif.xml:49(title)
+msgid ""
+"<application>Massif</application> output for the unoptimized version of the "
+"<application>Same GNOME</application> program."
+msgstr ""
+"æ?ªä¼?å??ç??æ?¬ç?? <application>Same GNOME</application> ç¨?åº?ç?? "
+"<application>Massif</application> è¾?å?ºã??"
+
+#: C/optimization-massif.xml:56(para)
+msgid ""
+"<xref linkend=\"optimization-massif-FIG-output-unoptimized\"/> shows a "
+"typical postscript output from <application>Massif</application>. This is "
+"the result you would get from playing a single game of <application>Same "
+"GNOME</application> (version 2.8.0) and then quitting. The postscript file "
+"will have a name like <filename>massif.12345.ps</filename> and the text file "
+"will be called <filename>massif.12345.txt</filename>. The number in the "
+"middle is the process ID of the program that was examined. If you actually "
+"try this example you will find two versions of each file, with slightly "
+"different numbers, this is because <application>Same GNOME</application> "
+"starts a second process and <application>Massif</application> follows that "
+"too. We will ignore this second process, it consumes very little memory."
+msgstr ""
+
+#: C/optimization-massif.xml:59(para)
+msgid ""
+"At the top of the graph we see a large yellow band labelled gdk_pixbuf_new. "
+"This seems like an ideal candidate for optimization, but we will need to use "
+"the text file to find out what is calling gdk_pixbuf_new. The top of the "
+"text file will look something like this:"
+msgstr ""
+
+#: C/optimization-massif.xml:62(programlisting)
+#, no-wrap
+msgid ""
+"\n"
+"Command: ./same-gnome \n"
+"\n"
+"== 0 ===========================\n"
+"Heap allocation functions accounted for 90.4% of measured spacetime\n"
+"\n"
+"Called from:\n"
+"  28.8% : 0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
+"\n"
+"    6.1% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)\n"
+"\n"
+"    5.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)\n"
+"\n"
+"    3.5% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)\n"
+"        "
+msgstr ""
+
+#: C/optimization-massif.xml:77(para)
+msgid ""
+"The line with the '=' signs indicates how far down the stack trace we are, "
+"in this case we are at the top. After this it lists the heaviest users of "
+"memory in order of decreasing spacetime. Spacetime is the product of the "
+"amount of memory used and how long it was used for. It corresponds to the "
+"area of the bands in the graph. This part of the file tells us what we "
+"already know: most of the spacetime is dedicated to gdk_pixbuf_new. To find "
+"out what called gdk_pixbuf_new we need to search further down the text file:"
+msgstr ""
+
+#: C/optimization-massif.xml:80(programlisting)
+#, no-wrap
+msgid ""
+"\n"
+"== 4 ===========================\n"
+"Context accounted for 28.8% of measured spacetime\n"
+"  0x6BF83A: gdk_pixbuf_new (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
+"  0x3A998998: (within /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so)\n"
+"  0x6C2760: (within /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
+"  0x6C285E: gdk_pixbuf_new_from_file (in /usr/lib/libgdk_pixbuf-2.0.so.0.400.9)\n"
+"\n"
+"Called from:\n"
+"  27.8% : 0x804C1A3: load_scenario (same-gnome.c:463)\n"
+"\n"
+"    0.9% : 0x3E8095E: (within /usr/lib/libgnomeui-2.so.0.792.0)\n"
+"\n"
+"  and 1 other insignificant place\n"
+"        "
+msgstr ""
+
+#: C/optimization-massif.xml:95(para)
+msgid ""
+"The first line tells us we are now four levels deep into the stack. Below it "
+"is a listing of the function calls that leads from here to gdk_pixbuf_new. "
+"Finally there is a list of functions that are at the next level down and "
+"call these functions. There are, of course, also entries for levels 1, 2, "
+"and 3, but this is the first level to reach right down through the GDK code "
+"to the <application>Same GNOME</application> code. From this listing, we can "
+"see instantly that the problem code is load_scenario."
+msgstr ""
+
+#: C/optimization-massif.xml:98(para)
+msgid ""
+"Now that we know what part of our code is using all the spacetime we can "
+"look at it and find out why. It turns out that the load_scenario is loading "
+"a pixbuf from file and then never freeing that memory. Having identified the "
+"problem code, we can start to fix it."
+msgstr ""
+
+#: C/optimization-massif.xml:103(title)
+msgid "Acting on the Results"
+msgstr ""
+
+#: C/optimization-massif.xml:104(para)
+msgid ""
+"Reducing spacetime consumption is good, but there are two ways of reducing "
+"it and they are not equal. You can either reduce the amount of memory "
+"allocated, or reduce the amount of time it is allocated for. Consider for a "
+"moment a model system with only two processes running. Both processes use up "
+"almost all the physical RAM and if they overlap at all then the system will "
+"swap and everything will slow down. Obviously if we reduce the memory usage "
+"of each process by a factor of two then they can peacefully coexist without "
+"the need for swapping. If instead we reduce the time the memory is allocated "
+"by a factor of two then the two programs can coexist, but only as long as "
+"their periods of high memory use don't overlap. So it is better to reduce "
+"the amount of memory allocated."
+msgstr ""
+
+#: C/optimization-massif.xml:107(para)
+msgid ""
+"Unfortunately, the choice of optimization is also constrained by the needs "
+"of the program. The size of the pixbuf data in <application>Same GNOME</"
+"application> is determined by the size of the game's graphics and cannot be "
+"easily reduced. However, the amount of time it spends loaded into memory can "
+"be drastically reduced. <xref linkend=\"optimization-massif-FIG-output-"
+"optimized\"/> shows the <application>Massif</application> analysis of "
+"<application>Same GNOME</application> after being altered to dispose of the "
+"pixbufs once the images have been loaded into the X server."
+msgstr ""
+
+#: C/optimization-massif.xml:111(title)
+msgid ""
+"<application>Massif</application> output for the optimized <application>Same "
+"GNOME</application> program."
+msgstr ""
+"ä¼?å??å??ç?? <application>Same GNOME</application> ç¨?åº?ç?? <application>Massif</"
+"application> è¾?å?ºã??"
+
+#: C/optimization-massif.xml:118(para)
+msgid ""
+"The spacetime use of gdk_pixbuf_new is now a thin band that only spikes "
+"briefly (it is now the sixteenth band down and shaded magenta). As a bonus, "
+"the peak memory use has dropped by 200 kB since the spike occurs before "
+"other memory is allocated. If two processes like this where run together the "
+"chances of the peak memory usage coinciding, and hence the risk of swapping, "
+"would be quite low."
+msgstr ""
+
+#: C/optimization-massif.xml:121(para)
+msgid ""
+"Can we do better ? A quick examination of <application>Massif</"
+"application>'s text output reveals: g_strdup to be the new major offender."
+msgstr ""
+"æ??们å?¯ä»¥å??å¾?æ?´å¥½å??ï¼?å¿«é??æ£?æ?¥ <application>Massif</application> ç??æ??æ?¬è¾?å?ºæ?­"
+"示ï¼?g_strdup æ?¯æ?°ç??主ç?¯ã??"
+
+#: C/optimization-massif.xml:124(programlisting)
+#, no-wrap
+msgid ""
+"\n"
+"Command: ./same-gnome \n"
+"\n"
+"== 0 ===========================\n"
+"Heap allocation functions accounted for 87.6% of measured spacetime\n"
+"\n"
+"Called from:\n"
+"    7.7% : 0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)\n"
+"\n"
+"    7.6% : 0x43BC9F: (within /usr/lib/libgdk-x11-2.0.so.0.400.9)\n"
+"\n"
+"    6.9% : 0x510B3C: (within /usr/lib/libfreetype.so.6.3.7)\n"
+"\n"
+"    5.2% : 0x2A4A6B: __gconv_open (in /lib/tls/libc-2.3.3.so)\n"
+"        "
+msgstr ""
+
+#: C/optimization-massif.xml:139(para)
+msgid ""
+"If we look closer though we see that it is called from many, many, places."
+msgstr "å¦?æ??æ??们æ?´è?ªä¹ ç??æ?¥ç??ï¼?æ??们å??ç?°å®?ä»?å¾?å¤?å¾?å¤?å?°æ?¹è°?ç?¨ã??"
+
+#: C/optimization-massif.xml:142(programlisting)
+#, no-wrap
+msgid ""
+"\n"
+"== 1 ===========================\n"
+"Context accounted for  7.7% of measured spacetime\n"
+"  0x5A32A5: g_strdup (in /usr/lib/libglib-2.0.so.0.400.6)\n"
+"\n"
+"Called from:\n"
+"    1.8% : 0x8BF606: gtk_icon_source_copy (in /usr/lib/libgtk-x11-2.0.so.0.400.9)\n"
+"\n"
+"    1.1% : 0x67AF6B: g_param_spec_internal (in /usr/lib/libgobject-2.0.so.0.400.6)\n"
+"\n"
+"    0.9% : 0x91FCFC: (within /usr/lib/libgtk-x11-2.0.so.0.400.9)\n"
+"\n"
+"    0.8% : 0x57EEBF: g_quark_from_string (in /usr/lib/libglib-2.0.so.0.400.6)\n"
+"\n"
+"  and 155 other insignificant places\n"
+"        "
+msgstr ""
+
+#: C/optimization-massif.xml:158(para)
+msgid ""
+"We now face diminishing returns for our optimization efforts. The graph "
+"hints at another possible approach: Both the \"other\" and \"heap admin\" "
+"bands are quite large. This tells us that there are a lot of small "
+"allocations are being made from a variety of places. Eliminating these will "
+"be difficult, but if they can be grouped then the individual allocations can "
+"be larger and the \"heap admin\" overhead can be reduced."
+msgstr ""
+
+#: C/optimization-massif.xml:163(title)
+msgid "Caveats"
+msgstr "注æ??äº?项"
+
+#: C/optimization-massif.xml:164(para)
+msgid ""
+"There are a couple of things to watch out for: Firstly, spacetime is only "
+"reported as a percentage, you have to compare it to the overall size of the "
+"program to decide if the amount of memory is worth pursuing. The graph, with "
+"its kilobyte vertical axis, is good for this."
+msgstr ""
+
+#: C/optimization-massif.xml:167(para)
+msgid ""
+"Secondly, <application>Massif</application> only takes into account the "
+"memory used by your own program. Resources like pixmaps are stored in the X "
+"server and aren't considered by <application>Massif</application>. In the "
+"<application>Same GNOME</application> example we have actually only moved "
+"the memory consumption from client-side pixbufs to server-side pixmaps. Even "
+"though we cheated there are performance gains. Keeping the image data in the "
+"X server makes the graphics routines quicker and removes a lot of inter-"
+"process communication. Also, the pixmaps will be stored in a native graphics "
+"format which is often more compact than the 32-bit RGBA format used by "
+"gdk_pixbuf. To measure the effect of pixmaps, and other X resources use the "
+"<ulink type=\"http\" url=\"http://www.freedesktop.org/Software/xrestop";
+"\">xrestop</ulink> program."
+msgstr ""
+
+#: C/optimization-harmful.xml:3(title)
+msgid "Disk Seeks Considered Harmful"
+msgstr ""
+
+#: C/optimization-harmful.xml:5(para)
+msgid ""
+"Disk seeks are one of the most expensive operations you can possibly "
+"perform. You might not know this from looking at how many of them we "
+"perform, but trust me, they are. Consequently, please refrain from the "
+"following suboptimal behavior:"
+msgstr ""
+"ç£?ç??寻é??æ?¯æ?¨å?¯è?½é??å?°ç??æ??æ??è´µç??æ??ä½?ä¹?ä¸?ã??ä»?æ?¥ç??æ?§è¡?ç??æ?°é??ï¼?å?¯è?½ä¸?è?½äº?解å?°ï¼?ä½?"
+"è¿?æ?¯ç??ç??ã??ç?¸åº?å?°ï¼?请é?¿å??å¦?ä¸?次ä¼?ç??é??æ?©ï¼?"
+
+#: C/optimization-harmful.xml:10(para)
+msgid "Placing lots of small files all over the disk."
+msgstr "å?¨ç£?ç??中å?°å¤?å­?æ?¾å¾?å¤?å°?æ??件ã??"
+
+#: C/optimization-harmful.xml:15(para)
+msgid "Opening, stating, and reading lots of files all over the disk"
+msgstr "å?¨ç£?ç??中ï¼?å?°å¤?æ??å¼?ã??æ?¥ç??ã??读å??å¾?å¤?å°?æ??件ã??"
+
+#: C/optimization-harmful.xml:20(para)
+msgid ""
+"Doing the above on files that are laid out at different times, so as to "
+"ensure that they are fragmented and cause even more seeking."
+msgstr ""
+
+#: C/optimization-harmful.xml:25(para)
+msgid ""
+"Doing the above on files that are in different directories, so as to ensure "
+"that they are in different cylinder groups and and cause even more seeking."
+msgstr ""
+
+#: C/optimization-harmful.xml:30(para)
+msgid "Repeatedly doing the above when it only needs to be done once."
+msgstr ""
+
+#: C/optimization-harmful.xml:35(para)
+msgid "Ways in which you can optimize your code to be seek-friendly:"
+msgstr ""
+
+#: C/optimization-harmful.xml:40(para)
+msgid "Consolidate data into a single file."
+msgstr ""
+
+#: C/optimization-harmful.xml:45(para)
+msgid "Keep data together in the same directory."
+msgstr "å°?æ?°æ?®ä¿?æ??å?¨å??ä¸?个ç?®å½?中ã??"
+
+#: C/optimization-harmful.xml:50(para)
+msgid "Cache data so as to not need to reread constantly."
+msgstr "ç¼?å­?æ?°æ?®ä»¥é?¿å??å®?æ??é??读æ?°æ?®ã??"
+
+#: C/optimization-harmful.xml:55(para)
+msgid ""
+"Share data so as not to have to reread it from disk when each application "
+"loads."
+msgstr "å?±äº«æ?°æ?®ä»¥ä¾¿ä¸?å¿?æ¯?个ç¨?åº?é??è¦?æ?¶é?½ä»?硬ç??读å??ã??"
+
+#: C/optimization-harmful.xml:60(para)
+msgid ""
+"Consider caching all of the data in a single binary file that is properly "
+"aligned and can be mmaped."
+msgstr ""
+"è??è??å°?æ??æ??ç??æ?°æ?®ç¼?å­?å?¨å??个äº?è¿?å?¶æ??件中ï¼?并使æ??件正确对é½?并å?¯ä»¥å°?å?¶ mmapã??"
+
+#: C/optimization-harmful.xml:65(para)
+msgid ""
+"The trouble with disk seeks are compounded for reads, which is unfortunately "
+"what we are doing. Remember, reads are generally synchronous while writes "
+"are asynchronous. This only compounds the problem, serializing each read, "
+"and contributing to program latency."
+msgstr ""
+
+#: C/optimization-guide.xml:5(title)
+msgid "Optimizing GNOME Software"
+msgstr "ä¼?å?? GNOME 软件"
+
+#: C/optimization-guide.xml:8(publishername) C/optimization-guide.xml:56(para)
+msgid "GNOME Documentation Project"
+msgstr "GNOME æ??档项ç?®"
+
+#: C/optimization-guide.xml:11(year) C/optimization-guide.xml:15(year)
+msgid "2004-2005"
+msgstr "2004-2005"
+
+#: C/optimization-guide.xml:12(holder)
+msgid "Callum McKenzie"
+msgstr "Callum McKenzie"
+
+#: C/optimization-guide.xml:16(holder)
+msgid "Robert Love"
+msgstr "Robert Love"
+
+#: C/optimization-guide.xml:20(firstname)
+msgid "Callum"
+msgstr "Callum"
+
+#: C/optimization-guide.xml:21(surname)
+msgid "McKenzie"
+msgstr "McKenzie"
+
+#: C/optimization-guide.xml:24(firstname)
+msgid "Robert"
+msgstr "Robert"
+
+#: C/optimization-guide.xml:25(surname)
+msgid "Love"
+msgstr "Love"
+
+#: C/optimization-guide.xml:29(para)
+msgid ""
+"Permission is granted to copy, distribute and/or modify this document under "
+"the terms of the <citetitle>GNU Free Documentation License</citetitle>, "
+"Version 1.1 or any later version published by the Free Software Foundation "
+"with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. "
+"You may obtain a copy of the <citetitle>GNU Free Documentation License</"
+"citetitle> from the Free Software Foundation by visiting <ulink type=\"http"
+"\" url=\"http://www.fsf.org\";>their Web site</ulink> or by writing to: Free "
+"Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-"
+"1307, USA."
+msgstr ""
+
+#: C/optimization-guide.xml:41(para)
+msgid ""
+"Many of the names used by companies to distinguish their products and "
+"services are claimed as trademarks. Where those names appear in any GNOME "
+"documentation, and those trademarks are made aware to the members of the "
+"GNOME Documentation Project, the names have been printed in caps or initial "
+"caps."
+msgstr ""
+
+#: C/optimization-guide.xml:52(revnumber)
+msgid "0.1"
+msgstr "0.1"
+
+#: C/optimization-guide.xml:53(date)
+msgid "November 2007"
+msgstr "2007å¹´11æ??"
+
+#: C/optimization-guide.xml:55(para)
+msgid "William Johnston"
+msgstr "William Johnston"
+
+#: C/optimization-guide.xml:57(para)
+msgid "Intial conversion to docbook format."
+msgstr "å??å§?转æ?¢å?° docbook æ ¼å¼?ã??"
+
+#: C/optimization-guide.xml:63(para)
+msgid ""
+"Software can be optimized in many ways: for speed, program size, or memory "
+"use. This section contains guides and tutorials for optimizing your software."
+msgstr ""
+
+#. Put one translator per line, in the form of NAME <EMAIL>, YEAR1, YEAR2
+#: C/optimization-guide.xml:0(None)
+msgid "translator-credits"
+msgstr "YunQiang Su <wzssyqa gmail com>, 2010"