Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Given a specific running process, is there a way to find out what hardware element is currently the bottleneck for its operation? In other words, is its current computation CPU-bound, GPU-bound, memory-bound, IO-bound, etc?

Answers that work for Windows XP are preferable, but all answers are welcome.

EDIT: I'm thinking about processes that take the absolutely majority of system resources to themselves; so solutions that can help me find the current battleneck for the entire system (e.g. what element is working hard the most while the others are resting) is fine as well.

EDIT 2: someone has asked me this question and my answer was

Open your task manager and choose to view page faults for the application - a very high count hints that you do not have enough physical memory. Check out the CPU utilization - if it's constantly at 100% it's a sign it may not be fast enough for this real-time application.

That's what I would have done but it feels a bit amateur-ish, so I'm looking for more precise, complete ways to identify the offender.

share|improve this question
    
Anything less crude than “look at your task manager” is going to be very OS-specific, so I took the liberty of adding an OS tag. –  Gilles Nov 10 '10 at 23:07
    
@Gilles no problem, I guess it wasn't a good idea to make the question OS-agnostic in the first place. –  Oak Nov 11 '10 at 12:26

2 Answers 2

You can use the Microsoft XPERF tools to walk the stack and find bottle necks. You can only view the results on Vista/7 (or server 2008) but you can run the profile tool on XP. Pigs Can Fly has some really good articles on stackwalking with XPERF.

We used it to find bottlenecks in our boot speed, and finally had proof to show the company to remove some tools that were taking too much Disk IO at boot.

share|improve this answer
    
In order to "walk the stack" you're going to need debugging symbols for the application in question. –  Billy ONeal Nov 10 '10 at 18:50
    
Yes, but with just the windows debugging tools, you can see what system things it is waiting on, like disk, networking, video drivers, etc, by seeing how much time it spends on those tasks. That can let you know to try a newer driver, or faster disk, etc. –  Brian Nov 10 '10 at 19:02

You would need to use a profiler. You would probably also need access to the program's source code, or at least to debugging symbols.

share|improve this answer
    
I'm asking about external processes, ones that I have no special access to. Off-the-shelf non-customizable applications. –  Oak Nov 10 '10 at 18:47
    
Oak, as far as I know you can't do that. You can measure what's bottlenecking the machine as a whole, but without profiling you're not going to be able to figure out exactly what any particular process is doing (and you need the debugging symbols for that) –  Billy ONeal Nov 10 '10 at 18:50
    
@Billy Thanks for explaining. Measuring the bottleneck on the entire system is actually fine for me; I've edited my question accordingly. –  Oak Nov 10 '10 at 18:53
    
@Oak: Ok, if the bottleneck is disk related, then look at the HDD activity light on your machine. If it's constantly lit, it's disk bottlenecked. Look at task manager - if CPU is maxed out, then it's CPU limited. If physical memory is full, that is also displayed there. I'm not aware of any way of checking if an application is GPU bound though. –  Billy ONeal Nov 10 '10 at 19:21
1  
@Billy: That's a pretty naive way of looking at it. Your CPU could be running at 99%, and the application could still be IO-bound by the hard drive. The OP is essentially asking if there is a way to measure this without just looking at the activity light and task manager and approximating. –  Sasha Chedygov Nov 10 '10 at 23:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.