I am trying to perform empirical analysis of the time complexity of a data set of about 1000 Codes. I have annotated them manually (how does the algorithm scale with respect to the size of input), and now I am trying to regress timing data against my complexity equation Y=C+log X + X + X log X + X^2 + X^3 + X^4 + e^X
.
As a metric for execution time of the program, I am currently using the number of byte codes executed during program execution. This count can by found by the -XX countBytecodes
Flag in Hotspot JVM. I also tried running with and without -Xint
flag in hotspot JVM which forces the JVM to execute all bytecode in interpreted mode.
However the problem I am facing is, that the execution counts change when I run the same program twice. And due to this change is timing data, the regression results change. Furthar, when I run two different instances of the same code, The variation is huge in the verdict. I am not using timing data from System.currentTimeMillis/Nanos
for the same reason. (I ran the data 6 times sequentially for about 500 codes and 3 times in parallel in batches of 160 codes. The variation was huge. Even the correlation between these values was random ranging from 1.00 to .37 and even small negatives in some cases.)
So I am looking for alternate apporaches, which can be used as a metric for the running time of the program. The only constraint is that this metric should have a direct relationship with the performance of the code, and should give same count when the code is executed multiple times. (or atleast the correlation should be close to 1).
I do not want to run timing data multiple times and take mean/median count because that is slowing things down to a great extent.
And is there any other profiler that could give me the count of the number of byte codes executed, during execution of a code?
A related question by me.
I just want the execution counts to be same if two codes are identical, not otherwise. And my sample has trivial codes to solve small programming puzzles where huge hand optimizations are not possible. Its is possible to gain some improvement over other implementation, but mostly the big-O remains the same (and even if it varies is cool, as long as the execution counts show that). What I dont want is, that in the first run, I get some execution counts, which get categorized as linear, and running again (the same identical code), gets different execution counts, which get categorized as a different big-O.