We can do memory profiling and high level performance profiling using the remote performance monitor, and so far I haven't run into any issues unique to the 360 GPU, so I've been able to use PIX for any GPU-related profiling. Unfortunately, the 360's CPU is nothing like a desktop CPU, which means that it's easy to run into performance issues that are impossible to reproduce on a desktop PC (which means you can't run a CPU profiler on them). Does the XNA team have plans to either provide a basic CPU profiling tool, or give us access to the necessary APIs to build one of our own?

As-is, it's looking like I'm going to have to build my own profiler from scratch to run on the 360, and then shove all its output back to my desktop via Debug.WriteLine, which is going to make it pretty painful to work with. It'd be really nice if I could avoid wasting a bunch of time building a profiler just to get my DBP entry running at 60 consistently on people's 360s when it runs at thousands of frames per second on my desktop PC. At the very least, having some access to some basic APIs for the purpose of doing profiling on the 360 would be a great start - it'd drastically reduce the difficulty of building my own profiler. A debug-only API for sending raw data back to a desktop PC, perhaps, combined with some support for asking the 360 to instrument a given class and/or method and record timing data, would probably be enough for developers to track down 90% of their 360-specific performance issues.

If you ever watch the PIX for Xbox demos/talks from GDC/Gamefest you will see that it does memory and CPU profiling as well as the GPU that we are used to seeing in windows PIX.

I know we've raised it before but I've heard no rumblings in that area so my only suggestion is to put it in connect.

The ZMan:

If you ever watch the PIX for Xbox demos/talks from GDC/Gamefest you will see that it does memory and CPU profiling as well as the GPU that we are used to seeing in windows PIX.

I know we've raised it before but I've heard no rumblings in that area so my only suggestion is to put it in connect.

It's interesting to hear that CPU profiling is integrated into PIX instead of a separate tool (or into the remote performance monitor). At least that means they already have tools for doing this on the hardware (though I'd bet that they don't support managed code).

I've created an issue on connect. Thanks for your feedback.

I've voted for it.  I'm starting a piece of my project that will involve some heavy-duty CPU work, and I suspect I will run into performance issues on the Xbox.  I'm not looking forward to playing an optimization guessing game based on profling on the PC.

How about creating your own API for profiling which you can build into you code, using macro's + compiler defines to enable profiling in you game.
 
This would allow you to break down where all the time is being spent though rendering the results on screen and see which code needs to be optimised.

Jan Richardson:

How about creating your own API for profiling which you can build into you code, using macro's + compiler defines to enable profiling in you game.
 
This would allow you to break down where all the time is being spent though rendering the results on screen and see which code needs to be optimised.

err maybe in C++, but this is C#...

No macros. Compiler defines and method calls is about all you have.

Compiler defines should be all you need

Sure, we all could write a profile if we wanted. I think the overall desire is to not mangle source code and have everyone roll their own when there is a potentially viable option already available in PIX.

That would be great, but I wouldn't hold my breath. It seems the native Xbox people are very sensitive to the potential risks of letting non-professional programmers get ahold of any of their tools, and it would probably take some fancy footwork for the XNA team to manage to wrangle that. Given that they have bigger fish to fry (both announced features like avatars, video, etc, as well as unannounced and/or requested features like streaming audio, faster JIT, etc), I don't think that it's going to bubble to the top anytime soon.

I use a simple profiling library I wrote myself, which uses the IDisposable interface to time various sections and tie them to a specific accumulator.
The code looks something like:



When the profiled returned object goes out of scope, time is measured and accumulated into the profile handle. There's a global list of these handles for reporting; I use singleton disposables with ref counting; and some other fancy footwork to minimize impact, but that's the gist of it.

jwatte:

It seems the native Xbox people are very sensitive to the potential risks of letting non-professional programmers get ahold of any of their tools, and it would probably take some fancy footwork for the XNA team to manage to wrangle that.

Just to clarify one thing, you're talking about the same people. The XNA team is responsible for both the managed and native Xbox tools. There used to be two teams, but we merged a while ago now. The same team is responsible for Game Studio, the XDK, and DXSDK.

It's not really fair to say it's "us versus them" when we're actually all on the same side.

Like most things, this feature is not just arbitrarily missing because we don't want to share. There are technical difficulties in porting tools designed for development consoles to work on retail consoles.

The same team is responsible for Game Studio, the XDK, and DXSDK.

I'm seeing several instances of left and right hands not quite living up to that ideal, though...
Anyway, give us a faster JIT, and profiling can wait ;-)

jwatte:

The same team is responsible for Game Studio, the XDK, and DXSDK.

I'm seeing several instances of left and right hands not quite living up to that ideal, though...
Anyway, give us a faster JIT, and profiling can wait ;-)

I'm not surprised. Public-facing announcements/releases/etc tend to happen long after it's too late to start again. Aligning our two teams didn't retroactively align the things we'd been working on before.

I suspect what you want is higher-quality JIT output, rather than faster JIT compilation. This has always been a pretty high priority for us, but unfortunately we haven't had a great deal of influence in what happens to that piece of technology so far. We haven't given up yet, though. :)