I've just tried (again) to use DMD's built-in profiler, which sounds like a
great idea in theory. The problem is, it is DOG SLOW. A little benchmark
program I have put together runs in 0.04 seconds when compiled with
"-O", and in 2.75 seconds when compiled with "-O -profile". The program
that I actually want to profile is totally out of the question because I just
don't have the patience to wait for hours before even the initialization
phase is over, and even if I did the results would probably be totally
skewed from the profiler overhead anyway.

Have others made the same experience? Is there any chance the profiler might get faster? Also, are there any free alternatives to the built-in profiler on Windows?

-Clemens

Reply to Clemens,

> I've just tried (again) to use DMD's built-in profiler, which sounds
> like a
> great idea in theory. The problem is, it is DOG SLOW. A little
> benchmark
> program I have put together runs in 0.04 seconds when compiled with
> "-O", and in 2.75 seconds when compiled with "-O -profile". The
> program
> that I actually want to profile is totally out of the question because
> I just
> don't have the patience to wait for hours before even the
> initialization
> phase is over, and even if I did the results would probably be totally
> skewed from the profiler overhead anyway.
> Have others made the same experience? Is there any chance the profiler
> might get faster? Also, are there any free alternatives to the
> built-in profiler on Windows?
> 
> -Clemens
> 

I seem to recall something like that.

Can you split the tight loops into one file and the other stuff into others. Then you can compile the outer stuff with profiling and not the inner stuff. Once you known what sub tree to profile, just profile that. It would be kind of a pain, but it might be a lot faster.

gdc -pg works great for me.

Clemens Hofreither Wrote:

> I've just tried (again) to use DMD's built-in profiler, which sounds like a
> great idea in theory. The problem is, it is DOG SLOW. A little benchmark
> program I have put together runs in 0.04 seconds when compiled with
> "-O", and in 2.75 seconds when compiled with "-O -profile". The program
> that I actually want to profile is totally out of the question because I just
> don't have the patience to wait for hours before even the initialization
> phase is over, and even if I did the results would probably be totally
> skewed from the profiler overhead anyway.
> 
> Have others made the same experience? Is there any chance the profiler might get faster? Also, are there any free alternatives to the built-in profiler on Windows?
> 
> -Clemens