-3

A program I'm developing has two threads running similar but different task:

thread1:

timer1.start()
writeToExternalDB1(consumedData)
timer1.end()

thread2:

timer2.start()
writeToExternalDB2(consumedData)
timer2.end()

I want to compare the writing performance of the two external database. I have timers around the write operation so that I can collect some metrics. Those two threads are running concurrently.

My question is will this design give correct measurement result regarding to the time spent by each write operation?

My understanding is probably not because the processing time given by CPU to each thread may be different. Let's say for thread1, after timer1 started, cpu will not move forward to the followed write operation, but switch to processing thread2 instead. This may introduce some gaps between timer1.start() and writeToExternalDB1(consumedData). However, in that case, should we regard this gap as negligible if we are processing a lot of data? What should I do to give the correct measurement result?

2

First of all, realize that performance measurements never give correct results, just more or less incorrect ones. You're striving for less incorrect, so you need to eliminate the factors that introduce timing variations.

As @ErikEidt comments, measurements should first be taken on a quiet machine, i.e. without activity from parallel threads or processes. This gives you an approximate lower bound on the time spent on an operation. If you make several measurements in a row, you might notice that the first one or few are often a bit slower because caches need to be filled, worker threads need to be started, whatever...

Once you determined a lower bound on processing time, you might want to measure again in different scenarios with parallel activity to see what you can schedule in parallel and what you better keep running separately because it interferes too much. For example, if the two write jobs are taking relatively long and work on the same physical device, running them in parallel might more than double each job's runtime (thrashing), so running them in sequence would actually make the whole thing faster.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.