BCS Wrote:

> 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.
> 
> 

Hm, something like that might be doable, though it's certainly annoying. Can I compile some modules with "-profile" and some without, and the linker will "do the right thing"?

-Clemens

On Fri, 11 Jul 2008 04:44:47 +0400, Clemens Hofreither <clemens.hofreither@gmx.net> wrote:

> BCS Wrote:
>
>> 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.
>>
>>
>
> Hm, something like that might be doable, though it's certainly annoying. Can I compile some modules with "-profile" and some without, and the linker will "do the right thing"?
>
> -Clemens

Yes, you can. Some module will get instrumented, while others wont.
You can have a look into profiler implementation in phobos/internal/trace.d

You can write your own implementation, too!