-1

i am trying to measure the execution time. i'm on windows 10 and use gcc compiler.

start_t = chrono::system_clock::now();
tree->insert();
end_t = chrono::system_clock::now();
rslt_period = chrono::duration_cast<chrono::nanoseconds>(end_t - start_t);

this is my code to measure time about bp_w->insert() the function insert work internally like follow (just pseudo code)

insert(){
    _load_node(node);
    // do something //
    _save_node(node, addr);
}

_save_node(n){
    ofstream file(name);
    file.write(n);
    file.close();
}

_load_node(n, addr){
    ifstream file(name);
    file.read_from(n, addr);
    file.close();
}

the actual results is, read is number of _load_node executions. write is number of _save_node executions. time is nano secs.

read  write time
1     1     1000000
1     1     0
2     1     0
1     1     0
1     1     0
1     1     0
2     1     0
1     1     1004000
1     1     1005000
1     1     0
1     1     0
1     1     15621000

i don't have any idea why this result come and want to know.

유일해
  • 1
  • 1
  • 1
    Use `steady_clock` when doing measurements like this. – Ted Lyngmo May 19 '21 at 17:01
  • thank you for nice information. i'll try it, but curious about results. could you give any idea? i want to know why it happen. – 유일해 May 19 '21 at 17:04
  • 1
    Timing can be iffy. On Windows It's possible the minimum tick you can get is 1/64th of a second and that results in garbage results like hundreds of 0s followed by one 15 ms jump. `chrono` has the capability to give nanoseconds, but typically the system beneath it can't give you resolution anywhere near that. – user4581301 May 19 '21 at 17:07
  • I can only guess. The clock doesn't seem to support higher resolution than microseconds. Some inserts takes a very short time. It depends on what's going on in your code. The pseudo code you have above would most probably not compile. If you put together a [mre] it may be easier to say something about it. – Ted Lyngmo May 19 '21 at 17:12
  • If you're on windows, you can use [GetSystemTimePreciseAsFileTime](https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemtimepreciseasfiletime) or [QueryPerformanceCounter](https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps). – Paul Sanders May 19 '21 at 17:12

2 Answers2

2

What you are trying to measure is ill-defined.

"How long did this code take to run" can seem simple. In practice, though, do you mean "how many CPU cycles my code took" ? Or how many cycles between my program and the other running programs ? Do you account for the time to load/unload it on the CPU ? Do you account for the CPU being throttled down when on battery ? Do you want to account for the time to access the main clock located on the motherboard (in terms of computation that is extremely far).

So, in practice timing will be affected by a lot of factors and the simple fact of measuring it will slow everything down. Don't expect nanosecond accuracy. Micros, maybe. Millis, certainly.

So, that leaves you in a position where any measurement will fluctuate a lot. The sane way is to average it out over multiple measurement. Or, even better, do the same operation (on different data) a thousand (million?) times and divide the results by a thousand.

Then, you'll get significant improvement on accuracy.

In code:

start_t = chrono::system_clock::now();
for(int i = 0; i < 1000000; i++)
tree->insert();
end_t = chrono::system_clock::now();
Jeffrey
  • 11,063
  • 1
  • 21
  • 42
0

You are using the wrong clock. system_clock is not useful for timing intervals due to low resolution and its non-monotonic nature.

Use steady_clock instead. it is guaranteed to be monotonic and have a low enough resolution to be useful.

Casey
  • 10,297
  • 11
  • 59
  • 88
  • *gaurenteed to be monotonic and have a low enough resolution to be useful.* Yes to *monotonic*, no to *low enough resolution to be useful*. It does the best it can with the support the underlying system can provide. – user4581301 May 19 '21 at 17:15
  • This is true, but not enough yet. You can't time a single `insert` and expect a meaningful reading. What if this one got (or didn't get) the one-off context switch or page fault? What if the OS decided this was the time for some important task. – Jeffrey May 19 '21 at 17:33