Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C# Stopwatch
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():
 
myStopwatch.Start();
mySimpleClass.doSth();
myStopwatch.Stop();
 
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 Smile | :) )
Posted 24-Sep-12 20:08pm
CyrusT190
Edited 1-Oct-12 14:12pm
v3
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

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.
  Permalink  
Comments
CyrusT at 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'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 at 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++)
p.mmm();
MessageBox.Show("" + DateTime.Now.Subtract(dt).TotalMilliseconds);
Sergey Alexandrovich Kryukov at 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.
--SA
Sergey Alexandrovich Kryukov at 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 at 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.
--SA
Mehdi Gholam at 2-Oct-12 0:43am
   
Cheers Sergey!
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 3

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.
 
—SA
  Permalink  
v2
Comments
Espen Harlinn at 1-Oct-12 18:12pm
   
Excellent :-D
Sergey Alexandrovich Kryukov at 1-Oct-12 18:12pm
   
Thank you very much, Espen.
--SA
Mehdi Gholam at 2-Oct-12 0:43am
   
5'ed
Sergey Alexandrovich Kryukov at 2-Oct-12 10:31am
   
Thank you, Mehdi.
--SA

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

  Print Answers RSS
0 Mathew Soji 330
1 BillWoodruff 260
2 Sergey Alexandrovich Kryukov 240
3 OriginalGriff 216
4 Afzaal Ahmad Zeeshan 208
0 OriginalGriff 6,168
1 Sergey Alexandrovich Kryukov 5,853
2 DamithSL 5,028
3 Manas Bhardwaj 4,539
4 Maciej Los 3,845


Advertise | Privacy | Mobile
Web04 | 2.8.1411019.1 | Last Updated 1 Oct 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100