Jump to content
  • Advertisement
Sign in to follow this  
Kaptein

Profiling

This topic is 530 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey all,

As the code slows to a crawl we have to instrument our binaries, but its been a while since I did programming on a platform that had options. I'm used to live stack sampling inside small kernels, and because of this I don't want to go back to the stone-age of fully instrumented executables.

I had a look at CxxProf: https://github.com/monsdar/CxxProf/wiki/What-is-CxxProf%3F and it looks nice. Especially the part where you can pick and choose where it does the work.

But, before I go ahead and do all this integration, what profilers do you use? Not to mention, CxxProf hasn't been updated in 3 years, although hopefully it still works well.

 

Actually, I have to sneak in a second question. I'm dividing my levels into a grid of X*X cells so that I only have to iterate over the cells (X-1 to X+1, Y-1 to Y+1) to find nearby objects. Using a "hash" of the cell position to assign objects to cells, where each cell has a set of objects. Does this sound like a plan?

Edited by Kaptein

Share this post


Link to post
Share on other sites
Advertisement

I actually prefer manually instrumented profiling over sampling profilers most of the time. It's easy to instantly see a big picture view of a frame, including when tasks are running relative to each other on different threads, and once a problem area is identified, it's easy to add more instrumentation into that area so that you can drill down in the next session. Sampling based methods are IMHO more noisy and not as easy to tell the time of a function in respect to a single frame.

I had a look at a bunch of libraries last time I needed one, but IIRC I couldn't find one that was as simple / bloat-free as I thought such a project should have been, so I wrote my own. Mine's ~400 LOC, including integration with my engine's thread pool and the code to serialize the output into chrome://tracing format for visualization, so it's not like it's a hard task to take on yourself -- profiler.hprofiler.cppprofiler_json.cpp

As for the second question, yes, if your cell size is bigger or equal you actually only have to inspect the contents of 4 cells (the 4 that are closest to the center of your search radius).

Share this post


Link to post
Share on other sites
23 minutes ago, Hodgman said:

I actually prefer manually instrumented profiling over sampling profilers most of the time. It's easy to instantly see a big picture view of a frame, including when tasks are running relative to each other on different threads, and once a problem area is identified, it's easy to add more instrumentation into that area so that you can drill down in the next session. Sampling based methods are IMHO more noisy and not as easy to tell the time of a function in respect to a single frame.

Yeah. live stack sampling is more of a "we don't have any other choice, because its hardware". It does have some positive traits though, eg. if the sampling source is bias-free then so are the samples. I'll defer to your experiences with full frame analysis. I always thought I would want to see data on a specific point and then "do things" in the game to figure out how that area changes in time-cost.

Your answer on the cells seem right to me. Sounds like uniform voronoi grid thing I did ages ago. Thanks.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!