ofasingle componntAtypcWebaracts(vi API)thWeb server. ICp ere are s with respec co Coding efficiency can also be subdivided,as shown in Figure 3. Figure 3.Refinement of the coding performance view Coding Con We split up coding efficiency into four items. Language constructs C++adds power and flexibility to its c ancestor.These added benefits do not come for free some C++language constructs may produce overhead in exchange.We will e throughout the book.This topic is,by na +specm the -it ju es that way.Developing however these architectural issues cannot be ignored since they can impact ally.Wh we must bear in mind that The cost of me .There are orders of mag ndcdioe r program d Cp turns Awareness of these issues helps software performance Libraries the choice of librar s used by an imple also affect nerfo nce for may perform task faster than others Bec to the library's source ode,it is hard to tel how li exampl mnt their services.For er string,you ca sprintf(string."&d"i): or an integer-to-ASClI function call [KR88]. itoa(i,string); Which one is more efficient?Is the difference significant? x • Program decomposition This involves decomposition of the overall task into communicating subtasks, object hierarchies, functions, data, and function flow. It is the program’s high-level design and includes component design as well as intercomponent communication. Few programs consist of a single component. A typical Web application interacts (via API) with a Web server, TCP sockets, and a database, at the very least. There are efficiency tricks and pitfalls with respect to crossing the API layer with each of those components. Coding efficiency can also be subdivided, as shown in Figure 3. Figure 3. Refinement of the coding performance view. We split up coding efficiency into four items: • Language constructs C++ adds power and flexibility to its C ancestor. These added benefits do not come for free—some C++ language constructs may produce overhead in exchange. We will discuss this issue throughout the book. This topic is, by nature, C++ specific. • System architecture System designers invest considerable effort to present the programmer with an idealistic view of the system: infinite memory, dedicated CPU, parallel thread execution, and uniform-cost memory access. Of course, none of these is true—it just feels that way. Developing software free of system architecture considerations is also convenient. To achieve high performance, however, these architectural issues cannot be ignored since they can impact performance drastically. When it comes to performance we must bear in mind that o Memory is not infinite. It is the virtual memory system that makes it appear that way. o The cost of memory access is nonuniform. There are orders of magnitude difference among cache, main memory, and disk access. o Our program does not have a dedicated CPU. We get a time slice only once in a while. o On a uniprocessor machine, parallel threads do not truly execute in parallel—they take turns. Awareness of these issues helps software performance. • Libraries The choice of libraries used by an implementation can also affect performance. For starters, some libraries may perform a task faster than others. Because you typically don’t have access to the library’s source code, it is hard to tell how library calls implement their services. For example, to convert an integer to a character string, you can choose between sprintf(string, “%d”, i); or an integer-to-ASCII function call [KR88], itoa(i, string); Which one is more efficient? Is the difference significant?