C++ Profiling: Which is faster: <...> or [...]?
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 1 of 1

Thread: C++ Profiling: Which is faster: <...> or [...]?

Threaded View

  1. #1
    Join Date
    Nov 2002
    Location
    Foggy California
    Posts
    1,245

    C++ Profiling: Which is faster: <...> or [...]?

    Q: Which is faster: <...> or [...]?
    Q: How can I optimize my code?

    A: You should probably be focussing on other things in your application like code correctness, readability, and maintainability.

    Why? Because a large percentage of people's attempts to optimize are:
    • attempts at micro-optimizations
    • are measured on a fixed platform -- neglecting portability
    • optimizing without good knowledge
    • optimizing too early
    • are ignoring efficient design principles


    Out of fear that people will not read the entire FAQ, I will start by focusing on the last point first.

    People need to practice efficient design principles

    Any experienced programmer knows that the key to an efficient application is efficient design. The problem is that nearly all attempts to optimize code (even by experts) lie outside this realm (experts usually have implemented a good design and thus don't need to optimize the design).

    "Good performance is a key design consideration of any serious project and its relative importance should be carefully weighed with all your other major considerations. So while I think itís a mistake to consider micro-optimizations early in your projectís life, I think it is vital to consider the performance goals of your project and design a solution that is going to be able to meet those goals from the outset."
    - Rico Mariani
    Efficient design is much more important that micro-optimizations. Micro-optimizations can lead to improvements of about 30% for typical computation-bound programs. For I/O bound programs, there may be no noticable improvement. On the other hand, efficient design can improve performance drastically (as an extreme example) turning a program that would take weeks to run into a program that takes seconds to run.

    What constitues efficient design? Well, that topic is quite large itself. Briefly, this includes things like choosing the correct algorithm (quicksort over bubblesort) and making sure you avoid creating too many temporary variables. There are many others. Here are a couple sites that have some suggestions:


    When to optimize
    Make it work.
    Make it right.
    Make it fast.
    - Kent Beck
    Optimize your code as the last step in your process. This need not be the last step for an entire application, but it should be the last step for a particular module. The reasons it should be done last:
    • A slow program that works is better than a optimized program that crashes.
    • A program should be maintainable (make it right)
    • Optimizations done early may be undone or be the wrong optimizations after the final code changes are made.


    How to optimize

    In general, you should not optimize for a particular platform. The reason is that the code may be ported to another operating system or even more common, the program will be run on a new family of processors. For example, programs optimized for Pentium I processors may not be well optimized for Pentium 4 processors. And they will almost always perform worse on a PowerPC platform than if no platform-specific optimizaiton was done at all.

    When you do optimize, use a profiler to identify the slow portions of your code and then work on optimizing the slow parts. If you optimize a piece of code that is not the bottleneck of your program, then people will not notice the improvements.

    Here is an interesting excerpt from a Digital Mars page on optimization (with a few minor edits):
    You can tune most C and C++ programs to a particular machine, and the global optimization feature does few transformations that you cannot duplicate at the source level. However, this kind of fine-tuning is usually not appropriate because:

    * Tuning code takes time. Compilers are meant to allow programmers to be more productive, and compiler optimization largely eliminates the need to tune programs by hand.
    * Cryptically tuned code is harder to maintain.
    * Code that is tuned for one machine may turn out to be poorly tuned for another. A widely applicable example of this problem is the fact that different compilers support different register values.
    * C++ is one of the few languages that permits implicit promotion of user-defined types; compiler optimization helps clean up the resulting temporary variables.

    Typical computation-bound programs can speed up as much as 30 percent when optimized. I/O-bound programs may not speed up at all. The most dramatic speed improvements are in small, frequently executed loops. Speed improves least in code that consists primarily of function calls.
    Other Quotes On the Subject
    "We should forget about small efficiencies, say about 97% of the time: Premature optimization is the root of all evil." - Donald Knuth
    Rules of Optimization:
    Rule 1: Don't do it.
    Rule 2 (for experts only): Don't do it yet.
    - M.A. Jackson
    "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." - W.A. Wulf

    Last edited by Andreas Masur; July 24th, 2005 at 06:43 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center