initial commit

3 files changed, 226 insertions, 0 deletions

diff --git a/files/zh-tw/tools/performance/allocations/index.html b/files/zh-tw/tools/performance/allocations/index.html
new file mode 100644
index 0000000000..e124139c49
--- /dev/null
+++ b/files/zh-tw/tools/performance/allocations/index.html
@@ -0,0 +1,86 @@
+---
+title: Allocations
+slug: Tools/Performance/Allocations
+translation_of: Tools/Performance/Allocations
+---
+<div class="summary">
+<p>The Allocations view in the Performance tool shows you which functions in your page are allocating the most memory over the course of the profile.</p>
+
+<p>For performance this is important mostly because allocating a lot of memory, or making a lot of allocations, can trigger <a href="/en-US/docs/Tools/Performance/Allocations#Allocations_and_garbage_collection">garbage collection</a>. This in turn can hurt the responsiveness of a page.</p>
+</div>
+
+<div class="geckoVersionNote">
+<p>The Allocations view is new in Firefox 46.</p>
+</div>
+
+<p>To enable the Allocations view, you must check "Record Allocations" in the Performance tool settings, <em>before</em> recording a profile. Then <a href="/en-US/docs/Tools/Performance/How_to#Record_a_profile">record a profile</a> as usual, and you will see a new tab labeled "Allocations" in the toolbar:</p>
+
+<p>{{EmbedYouTube("Le9tTo7bqts")}}</p>
+
+<h2 id="Anatomy_of_the_allocations_view">Anatomy of the allocations view</h2>
+
+<p>The allocations view looks something like this:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/12393/allocations-view-1.png" style="display: block; height: 156px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p>The allocations view periodically samples allocations that are made over the recording. Each row represents a function in which at least one allocation-sample was taken during the recording.</p>
+
+<p>It includes the following columns:</p>
+
+<ul>
+ <li>Self Count: the number of allocation-samples that were taken in this function (also shown as a percentage of the total)</li>
+ <li>Self Bytes: the total number of bytes allocated in the allocation-samples in this function (also shown as a percentage of the total)</li>
+</ul>
+
+<p>Rows are sorted by the "Self Bytes" column.</p>
+
+<p>So in the example above:</p>
+
+<ul>
+ <li>8904 samples were taken in <code>signalLater()</code>, which is 28.57% of the total number of samples taken</li>
+ <li>those samples allocated 1102888 bytes, which is 30.01% of the total memory allocated in all samples</li>
+</ul>
+
+<p>Next to each function name is a disclosure arrow. Click this to see the places this function was called from:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/12397/allocations-view-2.png" style="display: block; height: 155px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p>Here you can see that <code>signalLater()</code> was called from two places: <code>removeInner()</code> and <code>setSelectionInner()</code>. In this way you can walk back up the call stack, and understand better the context for these allocations.</p>
+
+<h3 id="Self_Cost_and_Total_Cost">Self Cost and Total Cost</h3>
+
+<ul>
+</ul>
+
+<p>You'll see that there are separate sets of columns for "Self" and for "Total". "Self" records samples taken only in this function. "Total" records samples taken in this function or in functions called by this function. At the top level, these are always the same, since the view presents "leaf" functions at the top level (that is, it presents an inverted view of the call stack). But if you start walking back up the call stack, you'll see the difference:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/12397/allocations-view-2.png" style="display: block; height: 155px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p>Here, 8904 samples were taken in <code>signalLater()</code>. But <code>signalLater()</code> was called from two places: <code>removeInner()</code> and <code>setSelectionInner()</code>. Both these functions have 0 in Self Count, meaning that no allocations were seen directly in these functions. However, <code>removeInner()</code> has 8901 in Total Count, while <code>setSelectionInner()</code> has just 3 in Total Count. This is telling us that, of the 8904 allocations seen in <code>signalLater()</code>, all but three came through the <code>removeInner()</code> branch.</p>
+
+<h2 id="Allocations_and_garbage_collection">Allocations and garbage collection</h2>
+
+<p>Of course, the memory allocated by a site is in itself useful information to know. But the main connection between the allocation profile of a site and its responsiveness is the cost of garbage collection (GC).</p>
+
+<p>With a garbage-collected language, like JavaScript, the runtime periodically needs to walk the heap looking for objects that are no longer <a href="/en-US/docs/Tools/Memory/Dominators#Reachability">reachable</a>, and then freeing the memory they occupy. While GC events like this are executing, the JavaScript engine must be paused, so your program is suspended and will be completely unresponsive.</p>
+
+<p>To reduce the impact on responsiveness, <a href="/en-US/docs/Mozilla/Projects/SpiderMonkey">SpiderMonkey</a> (the JavaScript engine in Firefox) can perform GC in small increments, letting the program run in between. Sometimes, though, it needs to perform a full non-incremental collection, and the program has to wait for it to finish.</p>
+
+<p>GC events are shown as red markers in the <a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a> view, and are a big red flag for responsiveness,  sometimes running for hundreds of milliseconds:</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/12399/allocations-view-long-gc.png" style="display: block; height: 160px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p>If you're seeing GC events in your site's performance profile, what can you do? SpiderMonkey uses a <a href="https://dxr.mozilla.org/mozilla-central/rev/584870f1cbc5d060a57e147ce249f736956e2b62/js/src/gc/GCRuntime.h#192">complex set of heuristics</a> to decide when to do what sort of garbage collection.</p>
+
+<p>In general, though:<em> allocation pressure - allocating a lot of memory, or allocating memory at a high rate - makes SpiderMonkey more likely to run garbage collection, and more likely to run full, non-incremental garbage collection.</em></p>
+
+<p>If a GC event was caused by allocation pressure, then the sidebar on the right of the marker in the Waterfall view contains a link labeled "Show allocation triggers". If you click this link, the devtools switches to the allocations view, and selects the region of time from the end of the last GC cycle to the start of the one you clicked on. This shows you all the allocations that collectively triggered this GC event:</p>
+
+<p>{{EmbedYouTube("tO5ovD9Jw4k")}}</p>
+
+<p>If you're seeing these problems, consider whether you can reduce the number or size of the allocations you're making here. For example:</p>
+
+<ul>
+ <li>can you allocate memory lazily, when it is actually needed, instead of up front?</li>
+ <li>if allocating memory in a loop, can you reuse a single allocation in every loop iteration?</li>
+</ul>
diff --git a/files/zh-tw/tools/performance/frame_rate/index.html b/files/zh-tw/tools/performance/frame_rate/index.html
new file mode 100644
index 0000000000..3c2c61467a
--- /dev/null
+++ b/files/zh-tw/tools/performance/frame_rate/index.html
@@ -0,0 +1,58 @@
+---
+title: Frame rate
+slug: Tools/Performance/Frame_rate
+translation_of: Tools/Performance/Frame_rate
+---
+<div class="summary">
+<p><font><font>幀速率是一個網站的響應的量度。</font><font>低或不一致的幀速率可以使一個網站出現反應遲鈍或janky，鬧了不好的用戶體驗。</font></font></p>
+
+<p><strong><font><font>60fps的幀頻是平穩的性能目標，給你所有需要響應某些事件更新的16.7毫秒時間預算。</font></font></strong></p>
+
+<p><font><font>在性能工具的幀速率圖表顯示你的幀速率在錄音的過程中。</font><font>它給你，你的網站可能是有問題，使您能夠使用其他工具進行更深入的分析的快速指示。</font></font></p>
+</div>
+
+<h2 id="幀速率和響應"><font><font>幀速率和響應</font></font></h2>
+
+<p><font><font>幀速率是指視頻設備可產生圖像（或幀）的速率。</font><font>這是從電影和遊戲最熟悉的，但現在被廣泛用作網站和Web應用程序性能的措施。</font></font></p>
+
+<p><font><font>在Web性能，幀封裝瀏覽器需要做的，以更新和重繪屏幕的工作。</font><font>幀速率是最明顯適用於動畫：如果幀速率太低，動畫將具有生澀外觀，而更快的幀速率會更順暢。</font><font>但幀速率也可用作站點的響應作為用戶的一般衡量與其交互。</font></font></p>
+
+<p><font><font>例如，如果移動鼠標在某個頁面元素觸發一些JavaScript改變元素的外觀，並觸發回流和重繪，那麼所有這些工作需要在該框架完成。</font><font>如果時間過長的瀏覽器來處理框架，那麼瀏覽器就會瞬間出現反應遲鈍（janky）。</font></font></p>
+
+<p><font><font>同樣，如果通過網頁滾動涉及到很多複雜的頁面更新和瀏覽器無法跟上一個可接受的幀速率，滾動頁面會出現遲緩或偶爾會凍結。</font></font></p>
+
+<p><font><font>在一般情況下，高和一致的幀速率將使用戶與網站的互動更愉快和吸引力。</font></font></p>
+
+<div class="note">
+<p><font><font>60fps的幀頻被算為是平穩的性能目標，給你所有的需要在應對某些事件做出同步更新16.7毫秒的時間預算。</font></font></p>
+
+<p><font><font>然而，一致性就顯得尤為重要：如果你不能提供60fps的，它是更好地實現較低的幀速率更穩定，並避免幀速率造成該網站凍結突然驟降。</font></font></p>
+</div>
+
+<h2 id="幀速率圖"><font><font>幀速率圖</font></font></h2>
+
+<p><font><font>幀速率曲線圖中找到</font></font><a href="/en-US/docs/Tools/Performance/UI_Tour#Recording_overview"><font><font>記錄概述</font></font></a><font><font>性能工具的一部分。</font><font>這需要當瀏覽器完成一幀的時間戳，並使用該跟踪幀速率的在記錄的過程中。</font></font></p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/11025/perf-frame-rate.png" style="display: block; height: 66px; margin-left: auto; margin-right: auto; width: 900px;"><font><font>x軸是時間上的信息期間，和有三個註釋：最大幀速率，平均幀速率和最低幀速率。</font></font></p>
+
+<h2 id="使用幀速率圖"><font><font>使用幀速率圖</font></font></h2>
+
+<p><font><font>幀速率曲線的巨大價值在於，像</font></font><a href="/en-US/docs/Tools/Web_Console"><font><font>Web控制台</font></font></a><font><font>，它給你，你的網站可能是有問題，使您能夠使用其他工具進行更深入的分析的快速指示。</font><font>例如，這裡有一個性能配置截圖：</font></font></p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/11023/perf-fr-waterfall.png" style="display: block; height: 413px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p><font><font>你可以看到，平均幀速率是相當健康的，但有三個點，其中幀頻為倒塌數十毫秒。</font><font>這肯定會導致明顯的口吃的，在網頁中播放任何動畫。</font></font></p>
+
+<p><font><font>幀速率圖表相關聯的</font></font><a href="/en-US/docs/Tools/Performance/UI_Tour#Timeline_summary"><font><font>瀑布摘要</font></font></a><font><font>直接上面，並且有我們可以看到，在第一兩滴在幀速率是相關的橙色酒吧，其中表示時間花費在執行的JavaScript。</font></font></p>
+
+<p><font><font>如果我們選擇了記錄這些片段之一，主</font></font><a href="/en-US/docs/Tools/Performance/Waterfall"><font><font>瀑布視圖</font></font></a><font><font>下它被放大到它，我們可以看到這是造成問題的功能：</font></font></p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/11027/perf-zoom.png" style="display: block; height: 504px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p><font><font>我們從一個點擊事件的阻止主線程170毫秒的JavaScript函數。</font></font></p>
+
+<p><font><font>它的功能有關係嗎？</font><font>切換到</font></font><a href="/en-US/docs/Tools/Performance/Flame_Chart"><font><font>火焰圖表</font></font></a><font><font>看到在那個點調用堆棧：</font></font></p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/11021/perf-fr-flame-chart.png" style="display: block; height: 413px; margin-left: auto; margin-right: auto; width: 900px;"></p>
+
+<p><font><font>有問題的函數被調用</font></font><code><font><font>doPointlessComputationsInMainThread（） </font></font></code><font><font>，</font><font>並且它在“main.js”定義。</font><font>為了解決這個問題，我們可能會考慮將其分割成塊，並運行裡面件</font></font><code><a href="/en-US/docs/Web/API/window/requestAnimationFrame"><font><font>requestAnimationFrame</font></font></a></code><font><font>，甚至運行在一個全功能</font></font><a href="/en-US/docs/Web/API/Web_Workers_API/Using_web_workers"><font><font>的工人</font></font></a><font><font>。</font><font>在</font></font><a href="/en-US/docs/Tools/Performance/Scenarios/Intensive_JavaScript"><font><font>密集的JavaScript</font></font></a><font><font>本文介紹如何使用這樣的策略，以修復因長期運行的JavaScript同步響應的問題。</font></font></p>
diff --git a/files/zh-tw/tools/performance/index.html b/files/zh-tw/tools/performance/index.html
new file mode 100644
index 0000000000..23ee0e1b61
--- /dev/null
+++ b/files/zh-tw/tools/performance/index.html
@@ -0,0 +1,82 @@
+---
+title: 效能
+slug: Tools/Performance
+tags:
+  - 效能
+translation_of: Tools/Performance
+---
+<p>效能工具給你網站整體反應度、JavaScript 與版面效能的洞察資訊。你可以使用效能工具在一段時間中錄製、測試你的網站的效能。這個工具會顯示瀏覽器在繪製你的網站時的所作之事，其總覽以及對應之<a href="/en-US/docs/Tools/Performance/Frame_rate">畫框率</a>的圖表。</p>
+
+<p>你可以在這三個子工具中，了解效能數據多方面的深入資訊：</p>
+
+<ul>
+ <li><a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a> 顯示瀏覽器的各種行為，諸如組版、JavaScript、重繪、回收資源等</li>
+ <li><a href="/en-US/docs/Tools/Performance/Call_Tree">Call Tree</a> 顯示瀏覽器花費在 JavaScript 函式上的時間</li>
+ <li><a href="/en-US/docs/Tools/Performance/Flame_Chart">Flame Chart</a> 顯示錄製全程中的 JavaScript 呼叫堆疊</li>
+</ul>
+
+<p>{{EmbedYouTube("WBmttwfA_k8")}}</p>
+
+<hr>
+<h2 id="由此開始">由此開始</h2>
+
+<div class="column-container">
+<div class="column-half">
+<dl>
+ <dt><a href="/en-US/docs/Tools/Performance/UI_Tour">UI Tour</a></dt>
+ <dd>
+ <p>從這裡開始探索效能工具，對介面的快速導覽。</p>
+ </dd>
+</dl>
+</div>
+
+<div class="column-half">
+<dl>
+ <dt><a href="/en-US/docs/Tools/Performance/How_to">How to</a></dt>
+ <dd>最基本的任務：開啟工具、建立、儲存、載入與設定錄製。</dd>
+</dl>
+</div>
+</div>
+
+<hr>
+<h2 id="效能工具的元件">效能工具的元件</h2>
+
+<div class="column-container">
+<div class="column-half">
+<dl>
+ <dt><a href="/en-US/docs/Tools/Performance/Frame_rate">Frame rate</a></dt>
+ <dd>了解你網站的整體回應速度。</dd>
+ <dt><a href="/en-US/docs/Tools/Performance/Call_Tree">Call Tree</a></dt>
+ <dd>尋找你網站中的 JavaScript 瓶頸。</dd>
+</dl>
+</div>
+
+<div class="column-half">
+<dl>
+ <dt><a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a></dt>
+ <dd>了解當用戶與你的網站互動時，瀏覽器在做些什麼。</dd>
+ <dt><a href="/en-US/docs/Tools/Performance/Flame_Chart">Flame Chart</a></dt>
+ <dd>看看錄製過程中某個 JavaScript 函式在那時執行。</dd>
+</dl>
+</div>
+</div>
+
+<hr>
+<h2 id="應用場景">應用場景</h2>
+
+<div class="column-container">
+<div class="column-half">
+<dl>
+ <dt><a href="/en-US/docs/Tools/Performance/Scenarios/Animating_CSS_properties">Animating CSS properties</a></dt>
+ <dd>使用 Waterfall 了解瀏覽器如何更新頁面，各種不同的 CSS 屬性動畫如何影響效能。</dd>
+ <dd> </dd>
+</dl>
+</div>
+
+<div class="column-half">
+<dl>
+ <dt><a href="/en-US/docs/Tools/Performance/Scenarios/Intensive_JavaScript">Intensive JavaScript</a></dt>
+ <dd>使用格率與 Waterfall 工具，以調查長時間執行的 JavaScript 帶來的效能問題，並了解如何使用 worker 來幫助解決問題。</dd>
+</dl>
+</div>
+</div>