path: root/files/ko/archive/b2g_os/성능/index.html

---
title: 성능
slug: Archive/B2G_OS/성능
translation_of: Web/Performance/Fundamentals
---
<p><span id="result_box" lang="ko"><span class="hps atn">성능</span><span>은</span> <span class="hps atn">광범위한 주제</span><span>입니다.</span> <span class="hps">본</span> <span class="hps">문서는</span> <span class="hps atn">Firefox OS</span><span>가</span> <span class="hps">어떻게</span> <span class="hps">설계</span> <span class="hps atn">및 최적화</span><span>되어</span> <span class="hps atn">있는지</span><span>의 관해</span> <span class="hps">대략적인</span> <span class="hps atn">개요</span><span>를</span> <span class="hps">설명합니다.</span> 그리고 <span class="hps">개발자가</span> <span class="hps atn">자신</span><span>의</span> <span class="hps">코드</span> <span class="hps atn">성능을 향상</span><span>시키는</span> <span class="hps">데 사용할 수있는</span> <span class="hps">도구와</span> <span class="hps">프로세스를</span> <span class="hps atn">소개</span><span>합니다.</span></span></p>
<h2 id="성능이란_무엇인가요">성능이란 무엇인가요?</h2>
<p><span id="result_box" lang="ko"><span class="hps atn">성능</span><span>은 전적으로</span> <span class="hps atn">사용자</span><span class="atn">에 의해 인식</span><span>됩니다.</span> <span class="hps">사용자가</span> <span class="hps atn">터치</span><span>, 이동,</span> <span class="hps">대화를 통해</span> <span class="hps atn">시스템</span><span>에</span> <span class="hps">입력</span> <span class="hps atn">정보를 제공</span><span>할때 </span><span class="hps">그</span> <span class="hps">대가로</span> <span class="hps atn">사용자</span><span>는</span> <span class="hps atn">시각적</span><span>,</span> <span class="hps">촉각</span> <span class="hps atn">적</span><span>,</span> <span class="hps">청각 적</span> <span class="hps atn">피드백 방식</span><span>에 의해</span> <span class="hps">출력</span> <span class="hps atn">정보</span><span>를 받습니다.</span> <span class="hps">성능은</span> <span class="hps">그</span> <span class="hps atn">입력</span><span class="atn">에 대한 응답</span><span>의</span> <span class="hps">출력</span> <span class="hps atn">품질</span><span>입니다.</span></span></p>
<p>유저 인식 성능(이 다음부터는 UPP라 부릅니다) 대신 다른 목적으로 최적화된 코드는 여러가지 타겟을 동등하게 최적화된 코드와 비교해서 떨어질수밖에 없습니다. 사용자는 프로세싱 성능이 떨어져도 응답성이 좋고 부드러운 응용 프로그램들을 선호합니다. 예를 들자면, 사용자들은 응답성이 좋으면서 부드럽지만 초당 1,000개의 데이터베이스 트렌젝션 처리를 하는 앱을 응답성이 좋지 않고 부드럽지 않지만 초당 100,000,000개의 데이터베이스 트렌젝션 처리를 하는 앱보다 선호할 것입니다.</p>
<p>당연히 데이터베이스 초당 트렌젝션 수같은 성능을 빠르게 처리하는게 의미가 없다는게 아닙니다; 그런건 당연히 의미가 있죠. 저희가 말하려는건 이런 것에 주를 두지 말고, UPP를 개선하는데 주를 둬야 한다는 것입니다.</p>
<p><span id="result_box" lang="ko"><span class="hps">성능에 관한 주요 </span><span class="hps atn">지표</span><span>는</span> <span class="hps">여러 가지</span>가 있습니다<span class="hps">.</span> <span class="hps">첫번째로</span> <span class="hps atn">"</span><span>응답성</span> <span class="hps atn">(</span><span class="atn">responsiveness</span><span class="atn">)</span><span class="atn">"</span><span>입니다.</span> 응답성은 <span class="hps">단순히</span> <span class="hps atn">사용자</span><span>의</span> <span class="hps atn">입력</span><span>에 대한 </span><span class="hps">시스템</span> <span class="hps">출력</span><span class="hps atn">(복수가</span><span> 될 수도</span> <span class="hps atn">있습니다</span><span class="atn">)의</span> <span class="hps">반환</span> <span class="hps atn">속도</span><span>입니다.</span> <span class="hps">예를 들어</span> <span class="hps">사용자가</span> <span class="hps atn">스크린</span><span>을</span> <span class="hps">누를</span> <span class="hps">때</span> 사용자들은<span class="hps"> </span><span class="hps atn">픽셀</span><span>에 어떤</span> <span class="hps">변화가</span> <span class="hps">일어난다고</span> <span class="hps">생각합니다.</span> <span class="hps atn">이 경우에는 "</span><span class="atn">탭</span><span class="atn">"</span><span class="atn">제스처</span><span>에서</span> <span class="hps atn">픽셀</span><span>이</span> <span class="hps">변경 될 때까지</span> <span class="hps">걸린 시간이</span> <span class="hps atn">응답성의 지표가 됩니다</span><span>.</span></span></p>
<p><span id="result_box" lang="ko"><span class="hps atn">응답성은</span> 자주 여러 단계의 피드백을  <span class="hps atn">필요로</span><span>합니다.</span> <span class="hps atn">응용 프로그램</span><span>의</span> <span class="hps atn">시작</span><span>은</span> <span class="hps">특히</span> <span class="hps">중요한</span> <span class="hps">사례</span> <span class="hps atn">중 하나이며</span><span>,</span> <span class="hps">이에 대해서는 나중에</span> <span class="hps atn">자세히 설명</span><span>합니다.</span></span></p>
<p>응답성은 간단히 아무도 무시되는걸 원하지 않는다는 단순한 이유 때문에 중요합니다. 사용자가 입력을 한 후에 시스템이 반응하기까지의 시간은 유저가 무시되는 시간입니다. 무시되는 것은 짜증과 화를 유발합니다.</p>
<p><span id="result_box" lang="ko"><span class="hps">다음으로 중요한</span> <span class="hps atn">지표</span><span>는</span> <span class="hps atn">"</span><span class="atn">프레임 레이트</span><span class="atn">"</span><span>입니다. 프레임 레이트란 </span><span class="hps atn">시스템</span><span>이</span> <span class="hps atn">사용자에게 표시</span><span class="atn">하는 픽셀</span><span>을</span> <span class="hps">변경</span>하는 속도입니다<span>.</span> <span class="hps">이것은 </span>흔한 컨셉이고<span class="hps"> </span><span class="hps">모두가</span> 좋아합니다<span>. 예를 들어 모든 사람은 </span> <span class="hps">초당 60</span> <span class="hps">프레임 레이트를 보여주는 게임은 </span><span>이유를</span> <span class="hps">설명</span> <span class="hps">할 수 없어도</span> <span class="hps">초당</span> <span class="hps">10</span> <span class="hps atn">프레임</span><span> 레이트를 보여주는</span> <span class="hps atn">게임</span><span>보다</span> </span>더 선호할 것입니다.</p>
<p>프레임 레이트는 "서비스의 질"의 지표로서 중요합니다. 컴퓨터의 디스플레이는 전자를 움직여서 현실을 모사하여 사용자들의 눈을 속이도록 디자인되어 있습니다. <span id="result_box" lang="ko"><span class="hps">예를 들자면, </span><span class="hps">문서</span> <span class="hps atn">리더</span><span>의</span> <span class="hps atn">디스플레이</span><span>는 실제</span> <span class="hps">종이의</span> <span class="hps">선명한</span> <span class="hps atn">텍스트</span><span>에</span> <span class="hps atn">반사되는 빛</span><span>과</span> <span class="hps">같은 패턴으로</span> <span class="hps atn">사용자</span><span>의</span> <span class="hps atn">망막</span><span>에</span> <span class="hps">닿는</span> <span class="hps">빛을</span> <span class="hps">생성하도록</span> <span class="hps">설계된</span> <span class="hps">디스플레이</span> <span class="hps atn">픽셀</span><span>을</span> <span class="hps atn">만들어 텍스트</span><span>를</span> <span class="hps">표시합니다.</span></span></p>
<p>현실에서는 동작은 "연속적입니다" (저희 두뇌가 알려주는 바에 따르면요); it's not jerky and discrete, but rather "updates" smoothly. (Strobe lights are fun because they turn that upside down, starving our brains of inputs to create the illusion of discrete reality.) On a computer display, a higher framerate simply allows the display to imitate reality more faithfully.</p>
<p>(흥미로운 점은 인간은 보통 60Hz 이상의 프레임 레이트를 구분하지 못한다는 것입니다. 그렇기 때문에 대부분의 현대의 전자식 디스플레이들은 60Hz로 디자인 되어 있습니다. 예를 들자면 TV 스크린은 벌새에게는 비자연스럽고 끊기는 것처럼 보일 것입니다.)</p>
<p>Memory usage is another key metric. Unlike responsiveness and framerate, users don't directly perceive memory usage. However, memory usage is a close approximation to "user state". An ideal system would maintain 100% of user state at all times: all applications in the system would run simultaneously, and all applications would retain the state created by the user the last time the user interacted with the application. (Application state is stored in computer memory, which is why the approximation is close.)</p>
<p>An important corollary of this is contrary to popular belief: a well-designed system should not be optimized to maximize the amount of <strong>free</strong> memory. Memory is a resource, and free memory is a unused resource. Rather, a well-designed system should be optimized to <strong>use</strong> as much memory as possible in service of maintaining user state, while meeting other UPP goals.</p>
<p>Optimizing a system to use memory doesn't mean it should <strong>waste</strong> memory. Using more memory than is required to maintain some particular user state is wasting a resource that could be used to retain some other user state.</p>
<p>In reality, no system can maintain all user state. Intelligently allocating memory to user state is an important concern that's discussed in more detail below.</p>
<p>The final metric discussed here is power usage. Like memory usage, users don't directly perceive power usage. Users perceive power usage indirectly by their devices being able to maintain all other UPP goals for a longer duration. In service of meeting UPP goals, the system must use only the minimum amount of power required.</p>
<p>The remainder of this document will discuss performance in terms of these metrics.</p>
<h2 id="폴랫폼_성능">폴랫폼 성능</h2>
<p>이 부분은 Firefox OS가 응용 프로그램 아래서 보통 어떻게 성능을 향상시키기 위해 공헌하는지에 대한 간략적 요약입니다. 앱 개발자나 유저의 입장에서 "이 폴랫폼이 저를 위해서 뭘 해줄수 있나요?" 라는 질문에 대한 대답입니다.</p>
<p>This section assumes the reader is familiar with the basic conceptual design of Firefox OS.</p>
<p>Firefox OS is optimized for applications built with web technologies, HTML/CSS/JavaScript and so on. Except for a handful of basic system services, all the code that runs in Firefox OS is web applications and the Gecko engine. Even the operating system window manager is written in HTML/CSS/JS.</p>
<p>Because the core operating system is built with the same web technologies that applications are built with, the performance of those technologies is critical. There's no "escape hatch". This greatly benefits developers because all the optimizations that enable a performant OS window manager, for example, are available to third-party applications as well. There's no "magic performance sauce" available only to preinstalled code.</p>
<p>The web platform provides many tools, some better suited for particular jobs than others. All application logic is written in JavaScript. For displaying graphics, developers can choose between the high-level declarative languages of HTML/CSS, or use low-level imperative interfaces offered by the canvas element.</p>
<p>HTML과 CSS는 생산성을 크게 증가시킵니다, pixel-level control over rendering or a few frames per second. Text and images are reflowed automatically, the system theme is applied to UI elements by default, and "built-in" support is provided for some use cases developers may not think about initially, like different-resolution displays or right-to-left languages.</p>
<p>The canvas element offers a pixel buffer directly to developers to draw on. This gives pixel-level control over rendering and precise control of framerate to developers. But it comes at the expense of extra work needed to deal with multiple resolutions and orientations, right-to-left languages, and so forth. Developers draw to canvases using either a familiar 2D drawing API, or WebGL, a "close to the metal" binding that mostly follows OpenGL ES 2.0.</p>
<p>(Somewhere "in between" HTML/CSS and canvas is SVG, which is beyond the scope of this document.)</p>
<p>The Gecko JavaScript engine supports just-in-time (JIT) compilation. This enables application logic to perform comparably to other virtual machines, such as Java virtual machines, and in some cases close to "native code".</p>
<p>The graphics pipeline in Gecko underlying HTML/CSS and canvas is optimized in several ways. The HTML/CSS layout and graphics code in Gecko minimizes invalidation and repainting for common cases likes scrolling; developers get this support "for free". Pixel buffers painted by both Gecko "automatically" and applications to canvas "manually" minimize copies when being drawn to the display framebuffer. This is done by avoiding intermediate surfaces where they would create overhead (such as per-application "back buffers" in many other operating systems), and by using special memory for graphics buffers that can be directly accessed by the compositor hardware. Complex scenes are rendered using the device's GPU for maximum performance. To improve power usage, simple scenes are rendered using special dedicated composition hardware, while the GPU idles or turns off.</p>
<p>Fully static content is the exception rather than the rule for rich applications. Rich applications use dynamic content with animations, transitions, and other effects. Transitions and animations are particularly important to applications. Developers can use CSS to declare even complicated transitions and animations with a simple, high-level syntax. In turn, Gecko's graphics pipeline is highly optimized to render common animations efficiently. Common-case animations are "offloaded" to the system compositor, which can render them both performantly and power efficiently.</p>
<p>The runtime performance of applications is important, but just as important is their startup performance. Firefox OS improves startup experience in several ways.</p>
<p>Gecko is optimized to load a wide variety of content efficiently: the entire Web! Many years of improvements targeting this content, like parallel HTML parsing, intelligent scheduling of reflows and image decoding, clever layout algorithms, etc, translate just as well to improving web applications on Firefox OS. The content is written using the same technologies.</p>
<p>Each web application has its own instance of the Gecko rendering engine. Starting up this large, complicated engine is not free, and because of that, Firefox OS keeps around a preallocated copy of the engine in memory. When an app starts up, it takes over this preallocated copy and can immediately begin loading its application resources.</p>
<p>Applications "start" most quickly when they're already running. To this end, Firefox OS tries to keep as many applications running in the background as possible, while not regressing the user experience in foreground applications. This is implemented by intelligently prioritizing applications, and discarding background applications according to their priorities when memory is low. For example, it's more disruptive to a user if their currently-playing music player is discarded in the background, while their background calculator application keeps running. So, the music player is prioritized above the calculator automatically by Firefox OS and the calculator is discarded first when memory is low.</p>
<p>Firefox OS prevents applications that are running in the background from impacting the user experience of foreground applications through two mechanisms. First, timers created by background apps are "throttled" to run at a low frequency. Second, background applications are given a low CPU priority, so that foreground applications can get CPU time when they need it.</p>
<p>In addition to the above, Firefox OS includes several features designed to improve power usage that are common to mobile operating systems. The Firefox OS kernel will eagerly suspend the device for minimal power usage when the device is idle. Relatedly, ICs like the GPU, cellular radio, and Wifi radio are powered down when not being actively used. Firefox OS also takes advantage of hardware support for media decoding.</p>
<h2 id="응용_프로그램_성능">응용 프로그램 성능</h2>
<p>This section is intended for developers asking the question: "how can I make my app fast"?</p>
<h3 id="시작_시간_성능">시작 시간 성능</h3>
<p>Application startup is punctuated by three user-perceived events, generally speaking. The first is the application "first paint": the point at which sufficient application resources have been loaded to paint an initial frame. Second is when the application becomes interactive; for example, users are able to tap a button and the application responds. The final event is "full load", for example when all the user's albums have been listed in a music player.</p>
<p>The key to fast startup is to keep two things in mind: UPP is all that matters, and there's a "critical path" to each user-perceived event above. The critical path is exactly and only the code that must run to produce the event.</p>
<p>For example, to paint an application's first frame that comprises visually some HTML and CSS to style that HTML, (i) the HTML must be parsed; (ii) the DOM for that HTML must be constructed; (iii) resources like images in that part of the DOM have to be loaded and decoded; (iv) the CSS styles must be applied to that DOM; (v) the styled document has to be reflowed. Nowhere in that list is "load the JS file needed for an uncommon menu"; "fetch and decode the image for the High Scores list"; etc. Those work items are not on the critical path to painting the first frame.</p>
<p>It seems obvious, but to reach a user-perceived startup event more quickly, the main "trick" is to just not run code that's off the critical path. Alternatively, shorten the critical path by simplifying the scene.</p>
<p>The web platform is highly dynamic. JavaScript is a dynamically-typed language, and the web platform allows loading code, HTML, CSS, images, and other resources dynamically. These features can be used to defer work at startup that's off the critical path, by loading the unnecessary content "lazily" some time after startup.</p>
<p>Another problem that can delay startup is idle time, caused by waiting on responses to requests like database loads. To avoid this problem, applications can "front load" the work by issuing requests as early as possible in startup. Then when the data is needed later, it's hopefully already been fetched and the application doesn't need to wait.</p>
<p>Relatedly, it's important to separate network requests for dynamic data from static content that can be cached locally. Locally-cached resources can be loaded much more quickly than they can be fetched over high-latency and lower-bandwidth mobile networks. Network requests should never be on the critical path to early application startup. Caching resources locally is also the only way applications can be used when "offline". Firefox OS allows applications to cache resources by either being "packaged" in a compressed ZIP file or "hosted" through HTML5 appcache. How to choose between these options for a particular type of application is beyond the scope of this document, but in general application packages provide optimal load performance; appcache is slower.</p>
<p>A few other hints are listed below:</p>
<ul>
 <li>
  <p>Don't include scripts or stylesheets that don't participate in the critical path in your startup HTML file. Load them when needed.</p>
 </li>
 <li>
  <p>Use the "defer" or "async" attribute on script tags needed at startup. This allows HTML parsers to process documents more efficiently.</p>
 </li>
 <li>
  <p>Don't force the web engine to construct more DOM than is needed. A "hack" to do this simply is to leave your HTML in the document, but commented out.</p>
  <pre>&lt;div id="foo"&gt;&lt;!--
  &lt;div&gt; ...
--&gt;&lt;/div&gt;</pre>
 </li>
 <li>
  <p>When that part of the document needs to be rendered, load the commented HTML.</p>
  <pre>foo.innerHTML = foo.firstChild.nodeValue;</pre>
 </li>
 <li>
  <p>Use Web Worker Threads for background processing. Only the application "main thread" can process user events and render primary UI. But a common use case is to fetch some data, process it, then update the UI. Use Worker Threads for this work and keep the main thread free for interacting with the user.</p>
 </li>
</ul>
<h3 id="프레임레이트">프레임레이트</h3>
<p>The first important consideration for achieving high framerate is to select the right tool for the job. Mostly static content that's scrolled and infrequently animated is usually best implemented with HTML/CSS. Highly dynamic content like games that need tight control over rendering, and don't need theming, is often best implemented with canvas.</p>
<p>For content drawn using canvas, it's up to the developer to hit framerate targets: they have direct control over what's drawn.</p>
<p>For HTML/CSS content, the path to high framerate is to use the right primitives. Firefox OS is highly optimized to scroll arbitrary content; this is usually not a concern. But often trading some generality and quality for speed, such as using a static rendering instead of a CSS radial gradient, can push scrolling framerate over a target. CSS media queries allow these compromises to be restricted only to devices that need them.</p>
<p>Many applications use transitions or animations through "pages", or "panels". For example, the user taps a "Settings" button to transition into an application configuration screen, or a settings menu "pops up". Firefox OS is highly optimized to transition and animate scenes that</p>
<ul>
 <li>Use pages/panels that are approximately the size of the device screen or smaller</li>
 <li>Transition/animate the CSS transform and opacity properties</li>
</ul>
<p>Transitions and animations that adhere to these guidelines can be offloaded to the system compositor and run maximally efficiently.</p>
<p>To help diagnose low framerates, see the section below.</p>
<h3 id="메모리와_전원_사용량">메모리와 전원 사용량</h3>
<p>Improving memory and power usage is a similar problem to speeding up startup: don't do unnecessary work; use efficient data structures; lazily load uncommonly-used UI resources; ensure resources like images are optimized well.</p>
<p>Modern CPUs can enter a lower-power mode when mostly idle. Applications that constantly fire timers or keep unnecessary animations running prevent CPUs from entering low-power mode. Power-efficient applications don't do that.</p>
<p>When applications are sent to the background, a visibilitychange event is fired on their documents. This event is a developer's friend; applications should listen for it. As mentioned above, Firefox OS tries to keep as many applications running simultaneously as it can, but does have to discard applications sometimes. Applications that drop as many loaded resources as possible when sent to the background will use less memory and be less likely to be discarded. This in turn means they will "start up" faster (by virtue of already being running) and have better UPP.</p>
<p>Similarly, applications should prepare for the case when they
 <i>
  are</i>
 discarded. To improve user-perceived memory usage, that is to say, making the user feel that more of their state is being preserved, applications should save the state needed to return the current view if discarded. If the user is editing an entry, for example, the state of the edit should be saved when entering the background.</p>
<h2 id="성능을_측정하고_문제를_분석하기">성능을 측정하고 문제를 분석하기</h2>
<p>성능을 측정하고 문제를 분석하기 전에, 이걸 기억하세요:</p>
<div class="geckoVersionNote">
 <blockquote>
   </blockquote>
 <blockquote>
  절대. 기기. 위에서. 테스트. 하세요.</blockquote>
 <blockquote>
   </blockquote>
</div>
<p>A great strength of the web platform is that the same code written for "desktop" web browsers runs on Firefox OS on mobile devices. Developers should use this to improve productivity: develop on "desktops", in comfortable and productive environments, as much as possible.</p>
<p>But when it comes time to test performance, mobile devices must be used. Modern desktops can be more than 100x more powerful than mobile hardware. The lower-end the mobile hardware tested on, the better.</p>
<p>With that caveat, the sections below describe tools and processes for measuring and diagnosing performance issues.</p>
<h3 id="성능을_측정하기">성능을 측정하기</h3>
<p>Firefox OS comes built-in with some convenient and easy-to-use tools that, when used properly, can be used to quickly measure performance. The first tool is the "framerate monitor". This can be enabled in the Firefox OS Settings application.</p>
<p>The framerate monitor continuously reports two numbers. The values reported are an average of recent results within a sliding window, meant to be "instantaneous" but fairly accurate. As such, both numbers are "guesses". The left number is the "composition rate": the estimated number of times per second Firefox OS is drawing frames to the hardware framebuffer. This is an estimate of the user-perceived framerate, and only an estimate. For example, the counter may report 60 compositions per second even if the screen is not changing. In that case the user-perceived framerate would be 0. However, when used with this caveat in mind and corroborated with other measurements, the monitor can be a useful and simple tool.</p>
<p><img alt="Screenshot of fps counter" src="http://people.mozilla.com/~cjones/mdn/enable-fps-counter.png" style="width: 320px; height: 480px;"></p>
<p>The rightmost number is the "layer transaction rate", the estimated number of times per second processes are repainting and notifying the compositor. This number is mostly useful for Gecko platform engineers, but it should be less than or equal to the composition rate number on the left.</p>
<p>Firefox OS also has a tool that can help measure startup time, specifically the "first paint" time described above. This "time-to-load" tool can be enabled using the Settings application. The value shown by the tool is the elapsed time between when the most recent application was launched, and an estimate of the first time that application painted its UI. This number only approximates the real "first paint" time, and in particular underestimates it. However, lowering this number almost always correlates to improvements in real startup time, so it can be useful to quickly measure optimization ideas.</p>
<p><img alt="Screenshot of enabling ttl" src="http://people.mozilla.com/~cjones/mdn/enable-ttl.png" style="width: 320px; height: 480px;"></p>
<p>For accurately measuring both startup times and responsiveness, a high-speed camera is indispensable. "High-speed" means that the camera can record 120 frames per second or above. The higher the capture rate, the more accurate the measurements that can be made. This may sound like exotic technology, but consumer models can be purchased for a few hundred US dollars.</p>
<p><a href="http://people.mozilla.com/~cjones/mdn/hs-example.webm" title="http://people.mozilla.com/~cjones/mdn/hs-example.webm">Link to example video of high-speed capture that I can't upload</a></p>
<p>The measuring process with these cameras is simple: record the action to be studied, and then play back the capture and count the number of frames that elapse between the input (say, a tap gesture) and the desired output (pixels changing in some way). Divide the number of counted frames by the capture rate, and the resulting number is the measured duration.</p>
<p>Mozilla built an automated tool called Eideticker which operates on the same principle as described above. The difference is that Eideticker uses synthetic user input events and HDMI capture to measure durations. The code is available and can be used with any device with an HDMI output.</p>
<p>Measuring power can be more difficult. It's possible to jury-rig measurement apparatus with a soldering iron, but a good approximation of power usage can be gathered by observing CPU load. Simple command-line tools like |top| allow monitoring CPU usage continuously.</p>
<p>In general, when measuring performance, don't be proud! "Primitive technology" like a stopwatch or logging, when used effectively, can provide eminently usable data.</p>
<h3 id="성능_문제를_분석하기">성능 문제를 분석하기</h3>
<p>If performance measurements show an application is below its targets, how can the underlying problem be diagnosed?</p>
<p>The first step of any performance work is to create a reproducible workload and reproducible measurement steps. Then gather baseline measurements, before any code changes are made. It seems obvious, but this is required to determine whether code changes actually improve performance! The measurement process selected isn't too important; what's important is that the process be (i) reproducible; (ii) realistic, in that it measures what users will perceive as closely as possible; (iii) precise as possible; (iv) accurate as possible. Even stopwatch timings can fit this spec.</p>
<p>Firefox OS includes two built-in tools for quickly diagnosing some performance issues. The first is a render mode called "paint flashing". In this mode, every time a region of the screen is painted by Gecko, Gecko blits a random translucent color over the painted region. Ideally, only parts of the screen that visually change between frames will "flash" with a new color. But sometimes more area than is needed is repainted, causing large areas to "flash". This symptom may indicate that application code is forcing too much of its scene to update. It may also indicate bugs in Gecko itself.</p>
<p><img alt="Enable paint flashing" src="http://people.mozilla.com/~cjones/mdn/enable-paint-flashing.png" style="width: 320px; height: 480px;"></p>
<p><img alt="Paint flashing after scrolling down from previous image" src="http://people.mozilla.com/~cjones/mdn/enable-paint-flashing-scroll-down.png" style="width: 320px; height: 480px;"></p>
<p>The second tool is called "animation logging", and can also be enabled in Settings. This tool tries to help developers understand why animations are not offloaded to the compositor to be run efficiently as possible. It reports "bugs" like trying to animate elements that are too large, or trying to animate CSS properties that can't be offloaded.</p>
<p><img alt="Enable animation logging" src="http://people.mozilla.com/~cjones/mdn/enable-log-animations.png" style="width: 320px; height: 480px;"></p>
<p><img alt="Start of animation not offloaded" src="http://people.mozilla.com/~cjones/mdn/enable-log-animations-1.png" style="width: 320px; height: 480px;"></p>
<pre>I/Gecko   ( 5644): Performance warning: Async animation disabled because frame size (1280, 410) is bigger than the viewport (360, 518) [div with id 'views']
</pre>
<p><img alt="End of animation not offloaded" src="http://people.mozilla.com/~cjones/mdn/enable-log-animations-2.png" style="width: 320px; height: 480px;"></p>
<div class="note">
 <p>A common pitfall is to animate left/top/right/bottom properties instead of using CSS transforms to achieve the same effect. For a variety of reasons, the semantics of transforms make them easier to offload, but left/top/right/bottom are much more difficult. Animation logging will report this.</p>
</div>
<p>These tools can help quickly assess a performance problem, but they often show only what developers should be "looking for": hints at deeper problems. When more information is required, the Gecko Profiler can be used. A full description of the profiler is beyond the scope of this document; see <a href="/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler" title="/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler">[here]</a>. Briefly, the profiler shows mixed JavaScript/C++ "samples" of what all Firefox OS processes are doing over a rolling time interval. Developers can use these profiles to see what their code and Gecko itself are doing. Warnings are built into the profiler UI for many common pitfalls like excessive garbage collection (caused by creating too many JS objects), and forcing "synchronous reflows". Sync reflows are bad because Gecko is optimized to do expensive work like reflows in big batches, when needed. Forced reflows throw off this "schedule", and can cause more work to be done than necessary.</p>
<p>Similarly, advanced users may wish to use a whole-system profiler like the linux |perf| tool. This is mostly useful for platform engineers, though.</p>
<p>As with measuring performance, don't be proud about tools used to diagnose it! A few well-placed Date.now() calls with logging can often provide a quick and accurate answer.</p>
<p>Finally, the only way to keep improving performance is to not regress it. The only way to not regress performance is to test it, preferably with automated tests. A full discussion of that topic is beyond the scope of this document, though.</p>
<h2 id="파리_Firefox_OS_성능_최적화_워크샵_3월_4_-_8일_2013">파리 Firefox OS 성능 &amp; 최적화 워크샵, 3월 4 - 8일, 2013</h2>
<p>To illustrate these concepts here are some videos and slides from the Paris Workshop dedicated to performances and optimizations.</p>
<p>파트 1: Technical basics and more (Gabriele &amp; Thomas)</p>
<ul>
 <li>비디오: <a href="https://docs.google.com/file/d/0ByB4v6HDNT-ZdHAtam5IdWpWWkE/edit?usp=sharing" title="https://docs.google.com/file/d/0ByB4v6HDNT-ZdHAtam5IdWpWWkE/edit?usp=sharing">Technical considerations</a></li>
 <li>슬라이드: <a href="https://docs.google.com/file/d/0ByB4v6HDNT-ZNGRxS3A1X21tMjQ/edit?usp=sharing" title="https://docs.google.com/file/d/0ByB4v6HDNT-ZNGRxS3A1X21tMjQ/edit?usp=sharing">Presentation</a></li>
</ul>
<p>파트 2: <a href="https://docs.google.com/file/d/0ByB4v6HDNT-ZWFNkRGtyTHd5TUU/edit?usp=sharing" title="https://docs.google.com/file/d/0ByB4v6HDNT-ZWFNkRGtyTHd5TUU/edit?usp=sharing">Performances in a UX point of view</a> (Josh)</p>
<p>파트 3: <a href="https://docs.google.com/file/d/0ByB4v6HDNT-ZdUVadVBmeDlXaW8/edit?usp=sharing" title="https://docs.google.com/file/d/0ByB4v6HDNT-ZdUVadVBmeDlXaW8/edit?usp=sharing">Performances measurement &amp; automation</a> (Julien &amp; Anthony)</p>