Optimizing your Code

Complete: 3

Common performance issues

Over-reliance on strings or mis-using std::string. Very large portions of CMS software are performance-limited by the reliance on strings, not by the numerical algorithms.

Recomputing values unnecessarily. This most often occurs in the form of x->y().z().w(), where "y" and "z" may not be as cheap as the developer assumed, or become excessively expensive when continuously recomputed for various reasons. The recomputation may be in a loop, but frequently if code has been split to dozens of small functions, it may simply occur because each function gets the value for one reason or another.

Looking up values in maps several times in a row. One possibility is to use "map.find(key)" instead of "map[key]", and then use the iterator returned. Another possibility is to save the reference returned by "map[key]" and reuse it several times.

Excessive sorting. Do not sort containers to find the smallest or largest element or the average value. Avoid sorting containers of large objects if a permutation vector can be used instead. Avoid sorting containers several times, especially on every insert. Be very careful with any sort involving floating point numbers and in particular where the sort key is computed, not taken directly from memory.

Spending time to compute values that are not used at all. If there are significant assymmetries in the usage patterns, make sure there is a "fast path" through the code for the most common ones.

Copying large objects, either passing too large objects by value, passing objects with significant memory allocations by value, or too frequently copying large object structures. Specifically using CLHEP dynamically sized vectors or matrices: HepMatrix, HepVector and related classes; use ROOT::Math instead.

Random access reading from compressed ROOT files, for example to sample from a profile. One alternative is to use several data files and choose randomly among them, then read in each file linearly. Another alternative is not to compress the data files. A third alternative is to pre-read all the data in memory.

Using the wrong compression algorithm. There are compression algorithms that have very different speed/compression ratio trade-off from that of ZLIB.

Common reasons for memory performance problems

We address here two major categories of memory performance: memory leaks and poor performance due to memory allocation or access patterns.

Memory leaks

The number one reason for memory leaks in CMS software is unclear object ownership and life time policy: who owns the object and is responsible for deletion, who may create references to the objects and when do references become invalid. Usually the code mixes smart pointers, reference counted objects, deep copies and passing by reference.

Above all, stick with maximally clear object life time policy that is manifestly clear to anyone reading the code. Developers reading code will in general make two assumptions: objects allocated on stack or passed by reference have "local" life time, and objects allocated on the heap with "new" have "extended" life time.

Thus, never take and keep the address of an object passed to you by reference by some function or method. Nobody reading the code will know to expect that someone is now holding a reference to the object they think is temporary. Conversely, if the object is a temporary, in general allocate it on stack, not on the heap. If you allocate the object on the heap, anyone reading the code will most likely assume other objects will start taking references to that object.it's because references to

or by reference are "temporary" (life time is what's "obviously" seen

Objects passed by reference or by value should never be mixed with objects

Never pass an object by reference ("void f(X &x)"), then take the address of the referenced object ("&x") and keep the pointer. Nobody reading the calling code will expect that.

Dynamically allocating objects then passing references to them is an indication someone might be

Memory allocation and access patterns

Review status

Reviewer/Editor and Date (copy from screen) Comments
LassiTuura - 17 Apr 2007 created page

Responsible: VincenzoInnocente
Last reviewed by: YourName - date

Edit | Attach | Watch | Print version | History: r11 | r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r2 - 2007-04-17 - LassiTuura



    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback