Scribd
Upload
29 views13 pages

Code Tuning Strategies

The document discusses various strategies for code tuning to improve a program's performance. It describes considering efficiency from the perspectives of program requirements, design, classes, routines, operating system interactions, and compilation before tuning code. The Pareto principle and common misconceptions about code tuning are explained. Common sources of inefficiency like input/output operations, paging, system calls, and interpreted languages are identified. Precise measurement of code performance is emphasized along with iterating the tuning process.

Uploaded by

Ateeqa Kokab
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
29 views13 pages

Code Tuning Strategies

The document discusses various strategies for code tuning to improve a program's performance. It describes considering efficiency from the perspectives of program requirements, design, classes, routines, operating system interactions, and compilation before tuning code. The Pareto principle and common misconceptions about code tuning are explained. Common sources of inefficiency like input/output operations, paging, system calls, and interpreted languages are identified. Precise measurement of code performance is emphasized along with iterating the tuning process.

Uploaded by

Ateeqa Kokab
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 13

Code Tunning Strategies

SAWERA NAWAZ 20011598-106


HADIQA ASIF 20011598-132
NOSHEEN SHAKEEL 20011598-115
Performance Overview

Code tuning is one way of improving a program’s performance. You can often find
other ways to improve performance more—and in less time and with less harm to
the code—than by code tuning. This section describes the options.
Performance and Code Tuning

Once you’ve chosen efficiency as a priority, whether its emphasis is on speed or on size, you
should consider several options before choosing to improve either speed or size at the code level.
Think about efficiency from each of these viewpoints:
o Program requirements
o Program design
o Class and routine design
o Operating-system interactions
o Code compilation
o Hardware
o Code tuning
Introduction to code tunning

Code tuning is appealing for several reasons. One attraction is that it seems to defy the laws of
nature. It’s incredibly satisfying to take a routine that executes in 20 microseconds, tweak a few
lines, and reduce the execution speed to 2 microseconds.
There are two principles for problems in code tunning.
o The pareto principle
o Old Wives’ Tales
The Pareto Principle

The Pareto Principle, also known as the 80/20 rule, states that you can get 80
percent of the result with 20 percent of the effort. The principle applies to a lot of
areas other than programming, but it definitely applies to program optimization.
Old Wives’ Tales

Much of what you’ve heard about code tuning is false, including the following common
misapprehensions: Reducing the lines of code in a high-level language improves the speed or size of
the resulting machine code—false! Many programmers cling tenaciously to the belief that if they can
write code in one or two lines, it will be the most efficient possible.
o Certain operations are probably faster or smaller than others—false!
o You should optimize as you go—false!
o A fast program is just as important as a correct one—false!
Kinds of Fat and Molasses

In code tuning you find the parts of a program that are as slow as molasses in winter and as big as
Godzilla and change them so that they are as fast as greased lightning and so skinny they can hide in
the cracks between the other bytes in RAM. You always have to profile the program to know with
any confidence which parts are slow and fat, but some operations have a long history of laziness and
obesity, and you can start by investigating them.
Common Sources of Inefficiency

Here are several common sources of inefficiency:


o Input output operations
o Paging
o System calls
o Interpreted languages
o Errors
Pagging
25.4 Measurement:

• Small parts of a program usually consume a disproportionate share of the run time, measure your
code to find the hot spots.
• Once you’ve found the hot spots and optimized them, measure the code again to assess how
much you’ve improved it.
• Many aspects of performance are counterintuitive.
• This code was straightforward, but performance of the matrix-summation routine was critical,
and i knew that all the array accesses and loop tests had to be expensive
Even though the code wasn’t as readable as the first code, especially to programmers who
aren’t C++ experts, I was magnificently pleased with myself.
Measurements Need to Be Precise;
• Performance measurements need to be precise. Timing your program with a stopwatch or by
counting “one elephant, two elephant, three elephant” isn’t precise. Profiling tools are useful, or
you can use your system’s clock and routines that record the elapsed times for computing
operations.

• Whether you use someone else’s tool or write your own code to make the measurements, make
sure that you’re measuring only the execution time of the code you’re tuning. Use the number of
CPU clock ticks allocated to your program rather than the time of day. Otherwise, when the
system switches from your program to another program,
25.5 Iteration:

Keep trying until you improve to an Extent .

You might also like