|optimizing c++ code (on win32 platform), all the techniques you know? firstname.lastname@example.org (Tzu-Chien Chiu) (2003-09-22)|
|Re: optimizing c++ code (on win32 platform) email@example.com (Scott McPhillips \[MVP\]) (2003-09-23)|
|Re: optimizing c++ code (on win32 platform) firstname.lastname@example.org (Jussi Jumppanen) (2003-09-23)|
|Re: optimizing c++ code (on win32 platform) email@example.com (2003-09-27)|
|Re: optimizing c++ code (on win32 platform) firstname.lastname@example.org (Oliver Wesnigk) (2003-09-27)|
|Re: optimizing c++ code (on win32 platform) email@example.com (2003-09-27)|
|Re: optimizing c++ code (on win32 platform) Brian.Inglis@SystematicSw.ab.ca (Brian Inglis) (2003-10-13)|
|Date:||27 Sep 2003 13:53:40 -0400|
|Organization:||AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com|
|Posted-Date:||27 Sep 2003 13:53:40 EDT|
Tzu-Chien Chiu <firstname.lastname@example.org> schreibt:
>"What methods do you ever use to optimize the programs?"
>We're developing a graphics chip emulator in C++, but it's very slow
>for big scenes.
IMO you should avoid virtual methods and sophisticated class
libraries, including most of the C++ standard classes. Universal class
libraries tend to offer many features, which require much indirection
and many runtime checks and decisions.
And the most important optimization, regardless of any language, is
the appropriate choice of the algorithms. Have you ever determined or
measured the order of your algorithms O(?), depending on the size of
Another idea: avoid mixing data types. Some compilers report hints or
warnings, about "mixing signed and unsigned data types". Such mixes
can require the implicit conversion of sub-expressions to the next
larger (common) data type, what can consume some time when e.g. int's
are converted to int64. Also avoid using 16 bit data types in 32 bit
x86 code, which require prefix bytes (opsize) and possibly also result
in implicit type conversions. The "native" data types in such an
environment have 8 or 32 bits.
Return to the
Search the comp.compilers archives again.