An interesting take on an old problem.
I personally turn profiler on for a while, capturing "statement completed" events for the database in question. I use a filter of reads >= 20 and duration > 1000 in order to cut down on the amount of data captured.
I find it irritating that you cannot (at least in 2000) specify NOT NULL in the filters.
Anyway, I usually always find some evil code that takes over a minute to run, and causes hundreds of thousands of disk reads.
It is quick and dirty, but it has not failed me yet.
And for those who are hyper-paranoid about the profiler causing performance problems of its own, I think that today's computers seem to be powerful enough to handle profiler for short bursts. I would rather solve the code-related problem quickly rather than worry too much about profiler induced problems.