🔒 Locked

Profiling results

Started by CpMan Aug 9, 2002 at 1:00 PM 1 replies 500+ views

Original Post

Aug 9, 2002 at 1:00 PM

I''ve recently been profiling my application (a particle engine), with both the Intel Vtune program and AMD CodeAnalyst. I''ve noticed two hits in this program that are extremely expensive, but for what reasons I have no idea. The top most expensive run time line is in the update function of the particle engine. The line is a simple m_Life += Elapsed_Time; //update the lifetime of this particle But it in fact takes up a HUGE amount of processor time relatively speaking. Compared to the rest of the lines in this function, some of which have 2, maybe 3 multiplications and additions, this one is nothing. The other line makes even less since. It''s the shortest function in the program, a simple access to private operator function, a boolean. yet it is the second most expensive function in the entire module. bool IsInitialized() {return m_Initialized}; No idea why this one is so expensive either. To make sure it wasn''t a fluke, I built the release version with debug info and profiled it too, same results. I think if I were to eliminate these bottlenecks, I''d probably be able to gain 30 or 40 fps, possibly more. Any help here. Ask me if you want the dissasmbly info. Athlon XP 2000+

don

Aug 9, 2002 at 9:10 PM

There''s no way you could have used the wrong pdb file when profiling is there? That would cause the profiler to call out the wrong line of code as the hot spot.

Have you had a look at the assembly language the compiler generated for those two spots? Does it look right?

If those results are valid then in the first case you listed, it could be due to a stall waiting on the result of a previous math operation.

In the next case you posted, why not make that an inline function?

You mentioned that you also verified this by making a release build with debug info. Does that mean you were profiling with a debug build before? Don''t ever do that. Always profile with a release build.

CpMan

Aug 9, 2002 at 11:17 PM

The second function is in fact inlined implictly, being implemented in the class - exactly as shown. I don'' know assembly toooo well, so it''s hard for me to tell whether it''s good and if not, how to fix it. It''s not possible to mix up the PDB files, and both profilers gave me the same result. The only thing I can think of is that it''s stalling because the line is the first line of the function, and operations used in initializing the function may be still going on. In the AMD code tests. I was averaging 13 cycles per instruction! on that line, and basically nothing elsewhere. I''m going to try moving the line down a few spots, towards the bottom of the function, and see whether that makes a difference, though for true optimal performance, I need to have it at the beginning, because if the m_Lifetime variable becomes greater than the maxliftime variable, I can skip the rest of the function.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.