On Jun 2, 2009, at 9:42 PM, Michael Bruck wrote:
On Wed, Jun 3, 2009 at 6:38 AM, Rick Altherr <kc8...@kc8apf.net> wrote:I'm speaking in general terms, but, yes, simple accessors can definitely be a problem depending how the program is structured. I've seen many a game engine written in C++ with full encapsulation where a statistical profile shows nearly all of the time in the prolog and epilog. The actual accessor doesn't cost anything (maybe 1-2 instructions), but the setup for the stack frame kills it. A stack frame setup forces accesses to memory so even though the number of instructions is small, the impact on the performance is significant. Having the instructions sit in the icache does help in termsof instruction fetch times, but the data operations involve aread-modify-write pattern which won't sit well in many cache structures.To be entirely fair, this problem with accessors mainly shows up when there are a large number of instances of the object and the accessor is beingcalled as part of a traversal over the instances.The typical solution is to allow direct access to the data member to avoidthe stack frame setup/teardown overhead.Wouldn't you have the accessor as inlined member function in C++ (while keeping the data private)? Michael
A good C++ compiler will automatically inline such functions at sufficient levels of optimization. Of course, there are limits as to what most compilers will inline and so this can really bite you. I've seen this fairly frequently on a lot of different source bases. Of course, everyone should be following the optimization creed: measure first, then optimize what is taking time. Otherwise you end up doing things like getting rid of all your accessor methods and find out it doesn't make any difference.
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
