পারফরমেন্স ফান্ডামেন্টাল

পারফরমেন্স কি ?

পারফরমেন্স ব্যপারটি সম্পূর্ণ ব্যবহারকারীর অনুভবের উপর নির্ভর করে। ব্যবহারকারীরা সিস্টেমে টাচ, নাড়াচাড়া এবং কথা বলার মাদ্ধমে ইনপুট দিয়ে থাকে। এর প্রতিদান হিসেবে তারা দৃষ্টিগোচর, স্পর্শ দ্বারা বোধগম্য এবং শোনা যায় এমন আউটপুট পায়। সোজা কথায় ইনপুটের সাপেক্ষে আউটপুটের কোয়ালিটি-ই হচ্ছে পারফরমেন্স।

ব্যবহারকারীর অনুভূত পারফরমেন্সের তোয়াক্কা না করে (UPP এর পর) শুধু একটি টার্গেটের জন্য অপ্টিমাইজ করা কোড, অন্য সব কিছুর সাম্যাবস্থা বজায় রেখে অপ্টিমাইজ করা কোডের সাথে প্রতিযোগিতায় হেরে যাবে। ব্যবহারকারীরা এমন একটি অ্যাপ চাইবে যেটা রেস্পন্সিভ এবং কোন প্রকার ঝামেলা করা ছাড়াই ১ সেকেন্ডে ১০০০ ডাটাবেজ কুয়েরি করতে সক্ষম। ব্যবহারকারীরা এমন অ্যাপ কখনোই চাইবে না, যেটা ১ সেকেন্ডে ১০০,০০০,০০০ কুয়েরি করতে পারে, কিন্তু রেস্পন্সিভও না আর প্রায়ই সমস্যা করে। অর্থাৎ কোন অ্যাপ কত শক্তিশালি, সেটা এখানে মুখ্য নয়; বরঞ্চ কে সবদিক ঠিক রেখে আমার সব কাজ মোটামুটি ভাবে চালিয়ে নিতে পারবে। আরও পরিস্কার করে বলতে হলে বলা যায়, যেকোনো একটি দিক নয়, একটি অ্যাপকে সব দিকই ঠিকঠাক ভাবে খেয়াল রাখতে হবে।

কিছু আবশ্যিক বিষয় আছে, যেটা একটি আদর্শ অ্যাপ তৈরির সময় খেয়াল রাখতে হয়। এই পাতার বাকী অংশে সেসব বিষয়ে আলোচনা করা হয়েছে।

রেসপন্সিভনেস

পারফরমেন্স এর ক্ষেত্রে সর্বপ্রথম যে বিষয়টি খেয়াল করা হয়, তা হল রেস্পন্সিভনেস। সহজভাবে এটা ব্যবহারকারীর দেয়া ইনপুটের বিপরীতে আউটপুট (বেশিরভাগ ক্ষেত্রে একাধিক হয়) প্রদানের গতিকে বোঝায়। উদাহরণ হিসেবে একজন ব্যবহারকারী যখন স্ক্রিনে টাচ করে, তখন আশা করে যে স্ক্রিনের পিক্সেল গুলো কিছুটা পরিবর্তিত হবে। এখানে টাচ করার ফলে পিক্সেলের পরিবর্তন হওয়াকে বলা হচ্ছে রেস্পন্সিভনেস। আর এটি ঘটতে যে পরিমাণ সময় লাগছে, তাকে বলা হচ্ছে রেসপন্স টাইম। এই রেসপন্স টাইম যত কম হবে, একটি অ্যাপ ততটাই রেস্পন্সিভ হবে।

রেস্পন্সিভনেস এর মধ্যে অনেক সময় একাধিক স্তরের প্রতিক্রিয়া থাকে। একটি অ্যাপ্লিকেশন চালু হওয়া একটি নির্দিষ্ট ও গুরুত্বপূর্ণ ঘটনা। নিচে এটা সম্পর্কে বিস্তারিত আলোচনা করা হয়েছে।

একটি সাধারণ কারণে রেস্পন্সিভনেস গুরুত্বপূর্ণঃ কেউ-ই স্লো অ্যাপ তথা অপেক্ষা করতে পছন্দ করে না। ইনপুট দেয়া এবং আউটপুট পাওয়া পর্যন্ত যত মিলিসেকেন্ড সময় লাগবে, ততক্ষণ একজন ব্যবহারকারীকে অপেক্ষা করতে হবে। মনে রাখবেন, অপেক্ষা মানুষের মাঝে হতাশা আর ক্ষোভ তৈরি করে। তাই প্রতিটি মিলিসেকেন্ড গুরুত্বপূর্ণ।

ফ্রেমরেট

সিস্টেম যে হারে পিক্সেল পরিবর্তন বা স্থানান্তর করে, তাকে বলা হয় ফ্রেমরেট। এটি একটি পরিচিত কনসেপ্টঃ একটি গেম প্রতি সেকেন্ডে ১০ টি ফ্রেম প্রদর্শন করতে পারে, তারচেয়ে সবাই সেকেন্ডে ৬০ টি ফ্রেম প্রদর্শন করতে পারে, এমন গেম পছন্দ করবে; যদি তারা ব্যাখ্যা নাও করতে পারে যে, কেন এটা তাদের পছন্দ!

"সেবার মান" নির্ধারণের ফ্রেমরেট একটি গুরুত্বপূর্ণ বিষয়। কম্পিউটারের ডিসপ্লে গুলো ব্যবহারকারীর চোখকে "বোকা" বানানোর Computer displays are designed to "fool" user's eyes, by delivering photons to them that mimic reality. For example, document readers display text by creating arrangements of display pixels that are designed to create photons that strike users' retinas in the same patterns as photons reflected off crisply-struck text on physical paper.

In reality, motion is "continuous" (as inferred by our brains anyway); 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.

মেমরি ব্যবহার

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.)

An important corollary of this is contrary to popular belief: a well-designed system should not be optimized to maximize the amount of free memory. Memory is a resource, and free memory is a unused resource. Rather, a well-designed system should be optimized to use as much memory as possible in service of maintaining user state, while meeting other UPP goals.

Optimizing a system to use memory effectively doesn't mean it should waste 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 in the system. 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.

পাওয়ার ব্যবহার

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.

The remainder of this document will discuss performance in terms of these metrics.

প্লাটফরম পারফরমেন্স অপটিমাইজেশন

This section provides a brief overview of how Firefox/Gecko contributes to performance generally, below the level of all applications. From a developer's or user's perspective, this answers the question "what does the platform do for you?"

ওয়েব প্রযুক্তি

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 and CSS, or use low-level imperative interfaces offered by the <canvas> element (which includes WebGL). Somewhere "in between" HTML/CSS and canvas is SVG, which offers some benefits of both.

HTML and CSS greatly increase productivity, sometimes at the cost of 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.

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.

গেকো রেন্ডারিং

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 even close to "native code".

The graphics pipeline in Gecko that underpins 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.

Fully static content is the exception rather than the rule for rich applications. Rich applications use dynamic content with animation and transition effects. Transitions and animations are particularly important to applications: developers can use CSS to declare complicated behaviour 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 in a performant and power efficient fashion.

The runtime performance of applications is important, but just as important is their startup performance. 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.

অ্যাপ্লিকেশন পারফরমেন্স

This section is intended for developers asking the question: "how can I make my app fast"?

স্টার্টআপ পারফরমেন্স

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.

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.

For example, to paint an application's first frame that comprises visually some HTML and CSS to style that HTML:

1. The HTML must be parsed
2. The DOM for that HTML must be constructed
3. Resources like images in that part of the DOM have to be loaded and decoded
4. The CSS styles must be applied to that DOM
5. 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.

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.

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.

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.

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", and for standard open web apps, at the moment this requires use of HTML5 AppCache.

ফ্রেমরেট

The first important consideration for achieving high framerate is to select the right tool for the job. Content that is mostly static, scrolled and infrequently animated is usually best implemented with HTML and CSS. Highly dynamic content like games that need tight control over rendering, and don't need theming, is often best implemented with Canvas.

For content drawn using Canvas, it's up to the developer to hit framerate targets: they have direct control over what's drawn.

For HTML and CSS content, the path to high framerate is to use the right primitives. Firefox 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.

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 is highly optimized to transition and animate scenes that

• Use pages/panels that are approximately the size of the device screen or smaller
• Transition/animate the CSS transform and opacity properties

Transitions and animations that adhere to these guidelines can be offloaded to the system compositor and run maximally efficiently.

মেমরি এবং ব্যাটারি ব্যবহার

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, and ensure resources like images are optimized well.

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 shouldn't do that.

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. 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, in the case of Firefox OS, see the note). This in turn means they will "start up" faster (by virtue of already being running) and have better UPP.

অ্যাপ্লিকেশন পারফরমেন্স এর জন্য কোডিং টিপস

The following practical tips will help improve one or more of the Application performance factors discussed above.

CSS এনিমেশন এবং ট্রানজিশন ব্যবহার করুন

Instead of using some library’s animate() function, which probably currently uses many badly performing technologies (window.setTimeout() or top/left positioning, for example) use CSS animations. In many cases, you can actually use CSS Transitions to get the job done. This works well because the browser is designed to optimize these effects and use the GPU to handle them smoothly with minimal impact on processor performance. Another benefit is that you can define these effects in CSS along with the rest of your app's look-and-feel, using a standardized syntax.

CSS animations give you very granular control over your effects using keyframes, and you can even watch events fired during the animation process in order to handle other tasks that need to be performed at set points in the animation process. You can easily trigger these animations with the :hover, :focus, or :target, or by dynamically adding and removing classes on parent elements.

If you want to create animations on the fly or modify them in JavaScript, James Long has written a simple library for that called CSS-animations.js.

CSS ট্রান্সফরম ব্যবহার করুন

Instead of tweaking absolute positioning and fiddling with all that math yourself, use the transform CSS property to adjust the position, scale, and so forth of your content. The reason is, once again, hardware acceleration. The browser can do these tasks on your GPU, letting the CPU handle other things.

In addition, transforms give you capabilities you might not otherwise have. Not only can you translate elements in 2D space, but you can transform in three dimensions, skew and rotate, and so forth. Paul Irish has an in-depth analysis of the benefits of translate() from a performance point of view. In general, however, you have the same benefits you get from using CSS animations: you use the right tool for the job and leave the optimization to the browser. You also use an easily extensible way of positioning elements — something that needs a lot of extra code if you simulate translation with top and left positioning. Another bonus is that this is just like working in a canvas element.

setInterval() এর বদলে requestAnimationFrame() ব্যবহার করুন

Calls to window.setInterval() run code at a presumed frame rate that may or may not be possible under current circumstances. It tells the browser to render results even while the browser isn't actually drawing; that is, while the video hardware hasn't reached the next display cycle. This wastes processor time (and can even lead to reduced battery life on the user's device).

Instead, you should try to use window.requestAnimationFrame(). This waits until the browser is actually ready to start building the next frame of your animation, and won't bother if the hardware isn't going to actually draw anything. Another benefit to this API is that animations won't run while your app isn't visible on the screen (such as if it's in the background and some other task is operating). This will save battery life and prevent users from cursing your name into the night sky.

ইভেন্টগুলো সরাসরি পরিচালনা করুন

As old-school, accessibility aware web developers we love click events as they also come with the added benefit of supporting keyboard input. On mobile devices, these are too slow. You should use touchstart and touchend instead. The reason is that these don’t have a delay that makes the interaction with the app appear sluggish. If you test for touch support first, you don’t sacrifice accessibility either. For example, the Financial Times uses a library called fastclick for that purpose, which is available for you to use.

ইন্টারফেস সহজ করুন

One big performance issue we found in HTML5 apps was that moving lots of DOM elements around makes everything sluggish — especially when they feature lots of gradients and drop shadows. Simplyfying your look-and-feel and moving a proxy element around when you drag and drop helps a lot.

When, for example, you have a long list of elements (let’s say tweets), don’t move them all. Instead, keep in your DOM tree only the ones that are visible and a few on either side of the currently visible set of tweets. Hide or remove the rest. Keeping the data in a JavaScript object instead of accessing the DOM can vastly improve your app's performance. Think of the display as a presentation of your data rather than the data itself. That doesn’t mean you can't use straight HTML as the source; just read it once and then scroll 10 elements, changing the content of the first and last accordingly to your position in the results list, instead of moving 100 elements that aren’t visible. The same trick applies in games to sprites: if they aren’t currently on the screen, there is no need to poll them. Instead re-use elements that scroll off screen as new ones coming in.

অ্যাপ্লিকেশন পারফরমেন্স পর্যালোচনা

Firefox, Chrome and other browsers both include built-in tools that can help you diagnose slow page rendering.  In particular, Firefox's Network Monitor will display a precise timeline of when each network request on your page happens, how large it is, and how long it takes.

If your page contains JavaScript code that is taking a long time to run, the JavaScript profiler will pinpoint the slowest lines of code:

The Built-in Gecko Profiler is a very useful tool that provides even more detailed information about which parts of the browser code are running slowly while the profiler runs. This is a bit more complex to use, but provides a lot of useful details.

Using YSlow (which requires FireBug) provides extremely helpful recommendations for improving performance.  Many of the identified problems and suggested solutions identified will be especially useful for mobile browsers.  You should definitely run YSlow and follow its recommendations.

In particular, making a large number (dozens or hundreds) of network requests can take longer in mobile browsers.  Rendering of large images and CSS gradients can also take longer.  Simply downloading large files can take longer, even over a fast network, because mobile hardware isn't always fast enough to utilize all the available bandwidth.  For useful general tips on mobile web performance, have a look at Maximiliano Firtman's Mobile Web High Performance talk.

টেস্ট সমস্যা এবং বাগ সাবমিট করা

If the Firefox and Chrome developer tools don't help you find a problem, or if they seem to indicate that the problem is caused by the web browser, then try to provide a reduced test case that isolates the problem as much as possible. This can often help in diagnosing problems.

See if you can reproduce the problem by saving and loading a static copy of an HTML page (including any images/stylesheets/scripts it embeds).  If that works, you can then edit the static files to remove any private information, then send them to others for help (submit a Bugzilla report, for example, or host it on a server and share a URL.) You should laso share any profiling information you've collected using the tools listed above.