Click here to Skip to main content
15,799,019 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Why the access time of class members is high?

I created a simple class like this:
class A {
   public SimpleClass()
   public void doSth()

And by using Stopwatch class(in System.Diagnostics) I measured the
time of accessing doSth():


and I was shocked by the result!

although the method does nothing,the Access time was around: 0.04 millisecond(s)!
While measuring the time interval of much more calculations (hundreds of multiplication of float numbers) takes about 0.002 ms!

1.Is there any way to reduce this time?
2.Have I made any mistakes?
(I would be happy to know further info. on this topic :) )
Updated 1-Oct-12 14:12pm

Not resetting StopWatch is not the only mistake.

One much more general thing is: you should move JIT time out of the equation. I also should note that your repetition time is very low, so the JIT compilation of the method will be a serious factor. The method is usually JIT-compiled before you call it for the first time; and the compilation time is way greater then the call itself.

This is the correct way:

class A {
   // no need in "public SimpleClass() {}"
   internal void doSth() {   } // no need in public: don't provide more access than really required


A myInstance = new A();
myInstance.doSth(); // when this has executed, the method is certainly JIT-compiled, but does not have to be compiled sooner

// now, time it!

That's it. Now it will work correctly.

Share this answer
Espen Harlinn 1-Oct-12 18:12pm    
Excellent :-D
Sergey Alexandrovich Kryukov 1-Oct-12 18:12pm    
Thank you very much, Espen.
Mehdi Gholam 2-Oct-12 0:43am    
Sergey Alexandrovich Kryukov 2-Oct-12 10:31am    
Thank you, Mehdi.
Do your test 1000 times and recheck your results, you should see a difference.

A single call delay can be attributed to startup time of the CLR, JIT compilation etc.
Share this answer
CyrusT 25-Sep-12 1:58am    
@Mehdi: I did what you said 100,000 times( in a for loop)
and yet the result had no difference :(

besides I tested a Queue<int>'s Enqueue() and Dequeue() methods too,and I noticed that the running time of these methods are even worse! (about 0.2 ms! ,again in a 100,000 times loop )
Mehdi Gholam 25-Sep-12 3:05am    
The following executes in 2ms on my machine (0.02ns per call):
DateTime dt = DateTime.Now;
pp p = new pp();
for (int i = 0; i < 100000; i++)
MessageBox.Show("" + DateTime.Now.Subtract(dt).TotalMilliseconds);
Sergey Alexandrovich Kryukov 1-Oct-12 18:00pm    
OK, I explained how to fix the timing the way excluding the extra time for JIT compilation, which otherwise distorts the timing results.
Considering that, the code you show above is also not quite correct.
Please see my solution.
Sergey Alexandrovich Kryukov 1-Oct-12 17:50pm    
[OP commented:]

You're right!
I made mistake at my test!
when running the test for 100,000 times,I didnt reset the StopWatch timer in order to calculate each "for step" calculation time.
Sergey Alexandrovich Kryukov 1-Oct-12 17:51pm    
My 5, but I would elaborate on JIT -- this is the main contribution of the number of timed iteration is not big enough, and way too many developers don't understand it.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900