Re: Macros

From: Louis Solomon [SteelBytes] (louis_at_steelbytes.spam-is-bad.com)
Date: 02/03/04 

Date: Tue, 3 Feb 2004 13:14:18 +1100

life is not simple.
and neither are all the subtlies of optimizing code.

some rules of thumb
* stack variables vs static/global vars are not very different in speed or
size.
* member variables vs stack & static/global vars are slower
* virtual methods are usually slower then non virtual.
* non virtual methods are similar/same to static/global funcs for speed.
* only unroll 'inner' loops (and likewise, only inline 'inner' funcs).
* there is nothing like profiling to find out which is quicker. (run code
using both methods 1000 times in a loop, and compare times). 

-- 
Louis Solomon
www.steelbytes.com
"Bonj" <a@b.com> wrote in message 
news:u%23PYYMd6DHA.2404@TK2MSFTNGP11.phx.gbl...
> Consider the two following possible implementations of a program:
>
> one, written in C++. With classes (let's say, 2, of which there is 
> probably
> only about 5 instances instantiated at any one time). Lots of local
> variables and stack usage. Class isn't padded with dummy variables, 
> although
> byte alignment is set to 16 bytes (the maximum). The class has mainly 4 
> byte
> variables although one is a 16 byte one (a RECT).
>
> the second, written in plain old C. It is the same program as the first, 
> and
> in a lot of places is pretty much similar code. But instead of having a
> class (as C can't), it has a struct, all variables being 4 bytes (there is
> no RECT in the struct). The struct is padded manually to 128 bytes. 
> Instead
> of class functions, there are macros which operate on the struct. Instead 
> of
> having local variables, it has globals - so there is no usage of the stack
> so to speak for each function - it just does a job. Every function that
> returns a void (about 80% of them) is then converted  into a macro, so 
> that
> the only functions that the program actually needs to generate function
> overhead for are the system functions, such as WinMain and the WndProc, 
> and
> a couple of other main controlling functions - the rest is totally inline.
>
> Understandably, the first will obviously be a lot neater code. But I've
> decided to consider investigating the possibility of the second - to try 
> to
> gain as near to machine code performance as possible (even though I can't
> begin to understand machine code). So far it seems alright, and not too 
> ugly
> (to me, anyway).
> ASIDE from the benefits of having cleaner code - just speaking in terms of
> performance, how much better is the second approach likely to be? In the
> region of 0.000001% ?    or maybe 2% - 10% ? Or maybe about 0.1% - 1%?
>
> Those are the optons.
>
> Comments?
>
>

Relevant Pages

  • Re: Macros
    ... member variables vs stack & static/global vars are slower ... non virtual methods are similar/same to static/global funcs for speed. ... The struct is padded manually to 128 bytes. ...
    (microsoft.public.win32.programmer.ui)
  • Re: A solution for the allocation failures problem
    ... struct nested *ptr1; ... which would jump to label if the allocation failed. ... implemented for the stack under windows. ... So in the malloc instance I would say you make use of the pre-allocated reserve rather than freeing it so you can do further mallocs whilst recovering. ...
    (comp.lang.c)
  • Re: Stack
    ... members of the stack at any given time. ... struct stackelement{ ... struct stackelement item; ... The string you were using was an automatic variable. ...
    (comp.lang.c)
  • Re: Structs
    ... >> A struct is created, generally, in null memory. ... >> memory model ensures that a variable created on the stack retains a zero ... Note "Local variables are initialized to 0 before entry if the initalize ... case the C# compiler generates superflous code with the initobj instruction. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Value Types and Reference Types
    ... struct can be thought of as a lightweight version of a class. ... but C# itself doesn't mention the stack vs heap at all. ... able to say that local variables are always on the stack. ...
    (microsoft.public.dotnet.languages.csharp)