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

[Rainer Schuetze]

On 24.08.2012 19:35, timotheecour wrote:
> 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 factor should be CPU-cycles-per-second / 3579545, so my estimate was 
for a CPU that runs at about 1 - 3.5 GHz.

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

The time is a long, but for current CPU-clock-speeds multiplying it with 
1000000 limits the measurable time.

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

I would have guessed that it should not depend on the system the 
trace.log is generated as the D name mangling should be the same. And 
even if it is not, the profiler window still displays the mangled names.

If you have an example of a non-working trace.log, you can send it to 
me, and I'll have a look.