profiler issues: time overflows, conversion to seconds, gui/html output

[timotheecour]

Thanks,

> The trace code is in druntime/rt/trace.d. There you can see 
> that the ticks/sec is just set to the shown constant value for 
> anything but Windows, but RDTSC is used to read the processor 
> cycles. So the values are probably off by a factor of 300 to 
> 1000.

So I'm still not sure how to convert those numbers to seconds. Is 
there a deterministic way? Is the multiplicative factor (300 to 
1000) fixed on a given machine or what does it depend on ?

> The time in ms is calculated as (time * 1000000) / freq, so 
> with a processor speed of 2GHz, this will overflow after about 
> 2000s.

Why not use 64 bit integer instead of 32 bit for counter?

> This doesn't seem to explain negative values in your run, so 
> some random hints:
>
> - if you rerun the program, results will accumulate in trace.log

I ran it just once


> - if you are calling recursive functions from inside main, 
> there might be some issues with the timings of these functions 
> (from my own experience from writing a profiler, it can get 
> quite tricky to measure the execution time of recursive 
> functions), and these are used to calculate the FuncTime of 
> main.

No recursive functions

> Visual D lets you explore trace.log in a browse window inside 
> Visual Studio, but I guess this won't help you on OSX.

great! Is there a way to run it on a project build outside of 
visualD? I use a makefile instead of relying on visualD's build 
system. When I open the profiler window and open trace.log inside 
nothing is shown. Ideally all it should do is demangle symbols 
and convert to a table, so I'm assuming trace.log is 
self-contained.