Re: looking for a simple profiling idea
On Mon, 21 Jun 2010, Marcin Rodzik wrote:
I'm trying to optimize my program. The basic idea of it is that it
consists of a few separate threads each of which performs another
operation on an object. The objects which are undergone these operations
are passed over from one thread to another. Operations on each object
are performed sequentially, however, all the threads work concurrently.
So each thread performs a set of operations disjoint from those of the
Now I'd like to know which thread is the most computation-intensive,
i.e. which takes the most of the CPU time. Is there any simple way to
A normal profiler will tell you which methods consume the most time. If
you know which threads run which methods, you can fairly easily work out
which threads consume the most time.
What I came up with is re-writing the program so that one thread is used
and simply check the time each operation takes with double invocation of
I think you mean System.nanoTime().
However, it's not so easy. Moreover, I'd like to check the time in a
If your real environment is linux, run top and use the H command to list
threads. That will let you see which are using the most CPU time. What top
doesn't do (AFAIK) is let you record statistics over time to do a proper
analysis later. There are other tools for that, but you'd have to ask on a
Similar things probably exist for Windows, but i don't know the first
thing about that. Except that it has pinball!
it means that I want to include the time the threads are blocked waiting
for I/O and so on.
Another question which is not clear to me: What really happens when a
thread waits for incoming data e.g. from a socket? To what extent can
the other threads use the CPU?
A very great extent. When a thread is waiting - for IO, to acquire a lock,
for a page of memory to be brought in from virtual memory on disk (which
is really IO by another name) - it isn't doing anything at all. The OS
essentially puts it to sleep, or freezes it in time, or however you want
to think of it. There's some overhead to freezing it, and some overhead to
thawing it out again, and it uses the same amount of memory when frozen as
when running, but it doesn't use CPU time between being put in the
carbonite and being broken out again.
Which means if you're concerned about getting the most work out of your
processor, you *don't* want to include the time they're blocked for IO.
You will want to know about it for a more complete picture of your
system, though. On many unix systems, the iostat tool will give you a
system-level picture of how much time is being spent waiting for IO. I
don't know (a) how to do it at the thread level or (b) how to do it on
Bear in mind that in the time a thread is waiting for IO, another thread
or threads are typically running. That means it's a double-edged sword; as
long as you have enough computational work to do, the fact that some
threads spend a lot of time waiting for IO may not matter much.
No hay banda