Overhead on returning from a method

I have an A () method that handles some requests. This method, from the opening of the bracket until the moment of its return, once for +/- 70 ms. A good 50% of which comes from opening a connection, about 20% comes from real requests, 5-10% is used by some memory access, the rest (possibly) is used to dispose of the connection, commands and reader.

Although this big chunk of time used to process the connection is annoying enough, what worries me more is that when I call A () from method B ():

B() { var timer = Stopwatch.Startnew() A(); timer.Stop(); // elapsed: +/- 250ms Debugger.Break(); } 

Another 180 ms of lag is added, and I cannot understand why. I already tried to have A return null, which does not change anything.

The only disk I / O and network occur in A. I thought that the transfer from disk and network to local memory should happen in A, and so calling A from B should not depend on this, but apparently this is not the case ? Is this network latency that I'm experiencing here? If so, why does this also happen when I just allow B to return null?

I have no other explanation at the moment ...

  • Everything is in one assembly,
  • Measuring without an attached debugger doesn’t change anything,
  • The return "null" immediately shows 0 ms, returning the value null instead of the normal return value does not change anything (but imposes the idea in one way or another connected with the delay).

A is roughly implemented as follows, like any simple database access method. It is contrived, but shows the main idea and flow:

 A() { var totalTimer = Stopwatch.StartNew(); var stuff = new Stuffholder(); using(connection) { using(command) { using(reader) { // fill 'stuff' } } } totalTimer.Stop(); // elapsed: +/- 70ms return stuff; } 

Any ideas?

+7
c # sql-server latency networking
source share
2 answers

The overhead you see is related to just-in-time compilation. The first method B() called the method A() not originally compiled (it is partially compiled in the dll as IL), so you see a slight lag, while the compiler compiles A() into machine code.

When profiling a method call, it is important to call the method a large number of times and take the average time (discarding the first call if you want, although with a sufficient number of calls, the compilation overhead should be negligible).

+7
source share

Since you have access to the database in A (), you may run into name resolution problems on the network, so your first call will take even longer.

0
source share

All Articles