sysperfana/perfinvestigator/com.nokia.carbide.cpp.pi.doc.user/html/concepts/overview/sw_performance.htm
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/sysperfana/perfinvestigator/com.nokia.carbide.cpp.pi.doc.user/html/concepts/overview/sw_performance.htm Thu Feb 11 15:32:31 2010 +0200
@@ -0,0 +1,34 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+ <title>Software Performance</title>
+ <link href="../../../book.css" rel="stylesheet" type="text/css">
+</head>
+
+<body>
+<h2>Software Performance </h2>
+<p>Two fundamental goals in understanding software performance can be seen as:</p>
+<ol>
+ <li>The ability to know which part of the software the CPU is executing at any particular instance of time</li>
+ <li>The ability to know why the CPU is executing that particular software at that particular instance of time</li>
+</ol>
+<p>Obstacles in determining software performance include:</p>
+<ol>
+ <li>Since large amounts of software can be executed with a state-of-the-art CPU, the recorded information has to be brought to some kind of an abstract level before it can be analyzed.</li>
+ <li>The complexity of action-reaction chains within state-of-the-art mobile terminal software is so huge, that it is impossible to directly derive the fundamental causes.</li>
+</ol>
+<p>When a software performance profile attributes 100% of CPU load to a set of threads, it is wise to remember that the Symbian OS performs tasks (such as switching tasks, scheduling, and exception handling) that are not really part of any thread. So the load attributed to any thread in a particular time period is only approximate.</p>
+<p>At any particular time, the software executing can be known quite precisely. This is not however, the point at which the problem can be considered solved. On the contrary, the information that performance measurements are trying to look for is “the why”. By understanding why excessive execution takes place within certain parts of the software, the source of the problem is a bit clearer. After understanding the “why”, modifications that would change the behavior can be considered.</p>
+<p>There are no comprehensive patterns to solve a performance problem. However, it is possible to resolve several performance problems at once through modifications made to one critical point in the software (referred to as a bottleneck).</p>
+<h3>Profiler Characteristics</h3>
+<p>The Profiler uses periodic interrupts to gather trace information. When a periodic interrupt occurs, the processor runs an interrupt service routine (ISR). The ISR can determine the address of the instruction executing at the time of the interrupt. Also, the ISR runs in a privileged mode that lets the ISR gather information from the Symbian OS in ways that are not allowed while in user mode.</p>
+<p>Activities within ISRs must be brief, or they will disturb other processing. So the ISR records information in a memory buffer and uses delayed function calls (DFCs) to write the information to a debug port or file system. A DFC is a Symbian OS feature that lets an ISR request that the OS run a routine later. The OS processes DFCs after all outstanding ISRs have been processed, but before control is given back to the currently executing thread.</p>
+<h5>Related references</h5>
+<ul>
+ <li><a href="../perfanalysis/perfanalysis.htm">Software Performance Analysis</a></li>
+</ul>
+<div id="footer">Copyright © 2009 Nokia Corporation and/or its subsidiary(-ies). All rights reserved. <br>License: <a href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</a></div>
+</body>
+</html>
\ No newline at end of file