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.
