Numba : difference between first time execution and following executions












2















I just started to use numba to improve performance of my programs. I have reduce the case that I will present



import numba as nb
import numpy as np
from time import time


def dt_max(U,f, eps=1e-5):
return np.min( np.abs( U ) / ( np.abs( f ) + eps ) )

@nb.njit(cache=True)
def fast_dt_max(U,f, eps=1e-5):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


N=100
Niter = int(1e5)

x=np.linspace(-50,50,N)

t0 = time()
for i in range(Niter):
dt_max(x,x)
print('numpy',time()-t0)

t0 = time()
for i in range(Niter):
fast_dt_max(x,x)
print('numba' ,time()-t0)


I execute this entire file in spyder under the following distribution :



Python 3.5.5 |Anaconda custom (64-bit)| (default, Apr  7 2018, 04:52:34) [MSC v.1900 64 bit (AMD64)]
Type "copyright", "credits" or "license" for more information.


The problem is the following. When I execute for the first time this program, it looks work good :



runfile('E:/02-Codes/TestCode/Python_numba/bug_second_execution.py', wdir='E:/02-Codes/TestCode/Python_numba')
numpy 0.45239996910095215
numba 0.2964000701904297


But when I repeat the execution of all file :



runfile('E:/02-Codes/TestCode/Python_numba/bug_second_execution.py', wdir='E:/02-Codes/TestCode/Python_numba')
numpy 0.45239996910095215
numba 3.5879998207092285

runfile('E:/02-Codes/TestCode/Python_numba/bug_second_execution.py', wdir='E:/02-Codes/TestCode/Python_numba')
numpy 0.4679999351501465
numba 3.5734000205993652


The numba's performance are not the same at all. If I restart Python kernel in my spyder environment, the problemn happens again : first execution is good, all the followings not.



So the first question is : why ? and the second is : how to avoid that ?



Thanks for your help










share|improve this question


















  • 1





    The problem seems to come from setting a default variable for eps. This causes a recompilation after reopening the interpreter. You can check this behaviour with setting the environment variable NUMBA_DEBUG_CACHE to one. eg. (set NUMBA_DEBUG_CACHE=1) and setting no default value for eps. If there are many cached versions for one function in the cache directory, this can also explain the very slow timing for loading the precached version.

    – max9111
    Nov 20 '18 at 10:15


















2















I just started to use numba to improve performance of my programs. I have reduce the case that I will present



import numba as nb
import numpy as np
from time import time


def dt_max(U,f, eps=1e-5):
return np.min( np.abs( U ) / ( np.abs( f ) + eps ) )

@nb.njit(cache=True)
def fast_dt_max(U,f, eps=1e-5):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


N=100
Niter = int(1e5)

x=np.linspace(-50,50,N)

t0 = time()
for i in range(Niter):
dt_max(x,x)
print('numpy',time()-t0)

t0 = time()
for i in range(Niter):
fast_dt_max(x,x)
print('numba' ,time()-t0)


I execute this entire file in spyder under the following distribution :



Python 3.5.5 |Anaconda custom (64-bit)| (default, Apr  7 2018, 04:52:34) [MSC v.1900 64 bit (AMD64)]
Type "copyright", "credits" or "license" for more information.


The problem is the following. When I execute for the first time this program, it looks work good :



runfile('E:/02-Codes/TestCode/Python_numba/bug_second_execution.py', wdir='E:/02-Codes/TestCode/Python_numba')
numpy 0.45239996910095215
numba 0.2964000701904297


But when I repeat the execution of all file :



runfile('E:/02-Codes/TestCode/Python_numba/bug_second_execution.py', wdir='E:/02-Codes/TestCode/Python_numba')
numpy 0.45239996910095215
numba 3.5879998207092285

runfile('E:/02-Codes/TestCode/Python_numba/bug_second_execution.py', wdir='E:/02-Codes/TestCode/Python_numba')
numpy 0.4679999351501465
numba 3.5734000205993652


The numba's performance are not the same at all. If I restart Python kernel in my spyder environment, the problemn happens again : first execution is good, all the followings not.



So the first question is : why ? and the second is : how to avoid that ?



Thanks for your help










share|improve this question


















  • 1





    The problem seems to come from setting a default variable for eps. This causes a recompilation after reopening the interpreter. You can check this behaviour with setting the environment variable NUMBA_DEBUG_CACHE to one. eg. (set NUMBA_DEBUG_CACHE=1) and setting no default value for eps. If there are many cached versions for one function in the cache directory, this can also explain the very slow timing for loading the precached version.

    – max9111
    Nov 20 '18 at 10:15
















2












2








2








I just started to use numba to improve performance of my programs. I have reduce the case that I will present



import numba as nb
import numpy as np
from time import time


def dt_max(U,f, eps=1e-5):
return np.min( np.abs( U ) / ( np.abs( f ) + eps ) )

@nb.njit(cache=True)
def fast_dt_max(U,f, eps=1e-5):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


N=100
Niter = int(1e5)

x=np.linspace(-50,50,N)

t0 = time()
for i in range(Niter):
dt_max(x,x)
print('numpy',time()-t0)

t0 = time()
for i in range(Niter):
fast_dt_max(x,x)
print('numba' ,time()-t0)


I execute this entire file in spyder under the following distribution :



Python 3.5.5 |Anaconda custom (64-bit)| (default, Apr  7 2018, 04:52:34) [MSC v.1900 64 bit (AMD64)]
Type "copyright", "credits" or "license" for more information.


The problem is the following. When I execute for the first time this program, it looks work good :



runfile('E:/02-Codes/TestCode/Python_numba/bug_second_execution.py', wdir='E:/02-Codes/TestCode/Python_numba')
numpy 0.45239996910095215
numba 0.2964000701904297


But when I repeat the execution of all file :



runfile('E:/02-Codes/TestCode/Python_numba/bug_second_execution.py', wdir='E:/02-Codes/TestCode/Python_numba')
numpy 0.45239996910095215
numba 3.5879998207092285

runfile('E:/02-Codes/TestCode/Python_numba/bug_second_execution.py', wdir='E:/02-Codes/TestCode/Python_numba')
numpy 0.4679999351501465
numba 3.5734000205993652


The numba's performance are not the same at all. If I restart Python kernel in my spyder environment, the problemn happens again : first execution is good, all the followings not.



So the first question is : why ? and the second is : how to avoid that ?



Thanks for your help










share|improve this question














I just started to use numba to improve performance of my programs. I have reduce the case that I will present



import numba as nb
import numpy as np
from time import time


def dt_max(U,f, eps=1e-5):
return np.min( np.abs( U ) / ( np.abs( f ) + eps ) )

@nb.njit(cache=True)
def fast_dt_max(U,f, eps=1e-5):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


N=100
Niter = int(1e5)

x=np.linspace(-50,50,N)

t0 = time()
for i in range(Niter):
dt_max(x,x)
print('numpy',time()-t0)

t0 = time()
for i in range(Niter):
fast_dt_max(x,x)
print('numba' ,time()-t0)


I execute this entire file in spyder under the following distribution :



Python 3.5.5 |Anaconda custom (64-bit)| (default, Apr  7 2018, 04:52:34) [MSC v.1900 64 bit (AMD64)]
Type "copyright", "credits" or "license" for more information.


The problem is the following. When I execute for the first time this program, it looks work good :



runfile('E:/02-Codes/TestCode/Python_numba/bug_second_execution.py', wdir='E:/02-Codes/TestCode/Python_numba')
numpy 0.45239996910095215
numba 0.2964000701904297


But when I repeat the execution of all file :



runfile('E:/02-Codes/TestCode/Python_numba/bug_second_execution.py', wdir='E:/02-Codes/TestCode/Python_numba')
numpy 0.45239996910095215
numba 3.5879998207092285

runfile('E:/02-Codes/TestCode/Python_numba/bug_second_execution.py', wdir='E:/02-Codes/TestCode/Python_numba')
numpy 0.4679999351501465
numba 3.5734000205993652


The numba's performance are not the same at all. If I restart Python kernel in my spyder environment, the problemn happens again : first execution is good, all the followings not.



So the first question is : why ? and the second is : how to avoid that ?



Thanks for your help







python numba execution-time






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 20 '18 at 8:40









lg53lg53

437




437








  • 1





    The problem seems to come from setting a default variable for eps. This causes a recompilation after reopening the interpreter. You can check this behaviour with setting the environment variable NUMBA_DEBUG_CACHE to one. eg. (set NUMBA_DEBUG_CACHE=1) and setting no default value for eps. If there are many cached versions for one function in the cache directory, this can also explain the very slow timing for loading the precached version.

    – max9111
    Nov 20 '18 at 10:15
















  • 1





    The problem seems to come from setting a default variable for eps. This causes a recompilation after reopening the interpreter. You can check this behaviour with setting the environment variable NUMBA_DEBUG_CACHE to one. eg. (set NUMBA_DEBUG_CACHE=1) and setting no default value for eps. If there are many cached versions for one function in the cache directory, this can also explain the very slow timing for loading the precached version.

    – max9111
    Nov 20 '18 at 10:15










1




1





The problem seems to come from setting a default variable for eps. This causes a recompilation after reopening the interpreter. You can check this behaviour with setting the environment variable NUMBA_DEBUG_CACHE to one. eg. (set NUMBA_DEBUG_CACHE=1) and setting no default value for eps. If there are many cached versions for one function in the cache directory, this can also explain the very slow timing for loading the precached version.

– max9111
Nov 20 '18 at 10:15







The problem seems to come from setting a default variable for eps. This causes a recompilation after reopening the interpreter. You can check this behaviour with setting the environment variable NUMBA_DEBUG_CACHE to one. eg. (set NUMBA_DEBUG_CACHE=1) and setting no default value for eps. If there are many cached versions for one function in the cache directory, this can also explain the very slow timing for loading the precached version.

– max9111
Nov 20 '18 at 10:15














1 Answer
1






active

oldest

votes


















1














Thanks a lot Max for the answer.



Indeed, the default value for eps is the reason of the problem. If I switch in debug mode (thanks Max for this tips!) :



import os
os.environ['NUMBA_DEBUG_CACHE'] = '1'
import numba as nb
import numpy as np
from time import time

@nb.njit(cache=True)
def fast_dt_max(U,f, eps=1e-5):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


This code shows that at each execution, 4 operations is done (2 loads, and 2 saving). Now if I remove the default value for eps, by keeping debug mode :



@nb.njit(cache=True)
def fast_dt_max(U,f, eps):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


the successive call to the function, let appear only 2 operations per execution (1 load + 1 saving)



CONCLUSION : Not use default parameter values in numba function.



Thanks !






share|improve this answer
























  • BTW: Your Numba and Numpy version are not equal. If a division by zero occurs the Numba version will act by default like Python and raise an exception. In Numpy a division by zero results in inf and you will see a Runtime Warning. If you write @nb.njit(cache=True,error_model="numpy") Numba will behave like Numpy, but without a runtime warning.

    – max9111
    Nov 20 '18 at 16:00











  • What do you mean by "Numba and Numpy version are not equal" ? My numba version is 0.40.1 and my numpy version is 1.14.5.

    – lg53
    Nov 21 '18 at 9:11











  • Good tips for error_model="numpy", it let to treat without error case with eps=0. Thanks !

    – lg53
    Nov 21 '18 at 9:13











  • I meant that in case of a division by zero your Numba version raises an exception without setting error_model="numpy", while the numpy function doesn't. That can lead to unwanted behaviour.

    – max9111
    Nov 21 '18 at 9:23











  • ok, not equal in the meaning that not works identically. I understand, thanks.

    – lg53
    Nov 21 '18 at 14:52











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53389113%2fnumba-difference-between-first-time-execution-and-following-executions%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














Thanks a lot Max for the answer.



Indeed, the default value for eps is the reason of the problem. If I switch in debug mode (thanks Max for this tips!) :



import os
os.environ['NUMBA_DEBUG_CACHE'] = '1'
import numba as nb
import numpy as np
from time import time

@nb.njit(cache=True)
def fast_dt_max(U,f, eps=1e-5):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


This code shows that at each execution, 4 operations is done (2 loads, and 2 saving). Now if I remove the default value for eps, by keeping debug mode :



@nb.njit(cache=True)
def fast_dt_max(U,f, eps):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


the successive call to the function, let appear only 2 operations per execution (1 load + 1 saving)



CONCLUSION : Not use default parameter values in numba function.



Thanks !






share|improve this answer
























  • BTW: Your Numba and Numpy version are not equal. If a division by zero occurs the Numba version will act by default like Python and raise an exception. In Numpy a division by zero results in inf and you will see a Runtime Warning. If you write @nb.njit(cache=True,error_model="numpy") Numba will behave like Numpy, but without a runtime warning.

    – max9111
    Nov 20 '18 at 16:00











  • What do you mean by "Numba and Numpy version are not equal" ? My numba version is 0.40.1 and my numpy version is 1.14.5.

    – lg53
    Nov 21 '18 at 9:11











  • Good tips for error_model="numpy", it let to treat without error case with eps=0. Thanks !

    – lg53
    Nov 21 '18 at 9:13











  • I meant that in case of a division by zero your Numba version raises an exception without setting error_model="numpy", while the numpy function doesn't. That can lead to unwanted behaviour.

    – max9111
    Nov 21 '18 at 9:23











  • ok, not equal in the meaning that not works identically. I understand, thanks.

    – lg53
    Nov 21 '18 at 14:52
















1














Thanks a lot Max for the answer.



Indeed, the default value for eps is the reason of the problem. If I switch in debug mode (thanks Max for this tips!) :



import os
os.environ['NUMBA_DEBUG_CACHE'] = '1'
import numba as nb
import numpy as np
from time import time

@nb.njit(cache=True)
def fast_dt_max(U,f, eps=1e-5):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


This code shows that at each execution, 4 operations is done (2 loads, and 2 saving). Now if I remove the default value for eps, by keeping debug mode :



@nb.njit(cache=True)
def fast_dt_max(U,f, eps):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


the successive call to the function, let appear only 2 operations per execution (1 load + 1 saving)



CONCLUSION : Not use default parameter values in numba function.



Thanks !






share|improve this answer
























  • BTW: Your Numba and Numpy version are not equal. If a division by zero occurs the Numba version will act by default like Python and raise an exception. In Numpy a division by zero results in inf and you will see a Runtime Warning. If you write @nb.njit(cache=True,error_model="numpy") Numba will behave like Numpy, but without a runtime warning.

    – max9111
    Nov 20 '18 at 16:00











  • What do you mean by "Numba and Numpy version are not equal" ? My numba version is 0.40.1 and my numpy version is 1.14.5.

    – lg53
    Nov 21 '18 at 9:11











  • Good tips for error_model="numpy", it let to treat without error case with eps=0. Thanks !

    – lg53
    Nov 21 '18 at 9:13











  • I meant that in case of a division by zero your Numba version raises an exception without setting error_model="numpy", while the numpy function doesn't. That can lead to unwanted behaviour.

    – max9111
    Nov 21 '18 at 9:23











  • ok, not equal in the meaning that not works identically. I understand, thanks.

    – lg53
    Nov 21 '18 at 14:52














1












1








1







Thanks a lot Max for the answer.



Indeed, the default value for eps is the reason of the problem. If I switch in debug mode (thanks Max for this tips!) :



import os
os.environ['NUMBA_DEBUG_CACHE'] = '1'
import numba as nb
import numpy as np
from time import time

@nb.njit(cache=True)
def fast_dt_max(U,f, eps=1e-5):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


This code shows that at each execution, 4 operations is done (2 loads, and 2 saving). Now if I remove the default value for eps, by keeping debug mode :



@nb.njit(cache=True)
def fast_dt_max(U,f, eps):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


the successive call to the function, let appear only 2 operations per execution (1 load + 1 saving)



CONCLUSION : Not use default parameter values in numba function.



Thanks !






share|improve this answer













Thanks a lot Max for the answer.



Indeed, the default value for eps is the reason of the problem. If I switch in debug mode (thanks Max for this tips!) :



import os
os.environ['NUMBA_DEBUG_CACHE'] = '1'
import numba as nb
import numpy as np
from time import time

@nb.njit(cache=True)
def fast_dt_max(U,f, eps=1e-5):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


This code shows that at each execution, 4 operations is done (2 loads, and 2 saving). Now if I remove the default value for eps, by keeping debug mode :



@nb.njit(cache=True)
def fast_dt_max(U,f, eps):
m=U[0]
if m<0 : m=-U[0]
for i in range(len(U)) :
v = abs(U[i]) / ( abs(f[i]) + eps )
if v < m : m = v
return m


the successive call to the function, let appear only 2 operations per execution (1 load + 1 saving)



CONCLUSION : Not use default parameter values in numba function.



Thanks !







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 20 '18 at 14:38









lg53lg53

437




437













  • BTW: Your Numba and Numpy version are not equal. If a division by zero occurs the Numba version will act by default like Python and raise an exception. In Numpy a division by zero results in inf and you will see a Runtime Warning. If you write @nb.njit(cache=True,error_model="numpy") Numba will behave like Numpy, but without a runtime warning.

    – max9111
    Nov 20 '18 at 16:00











  • What do you mean by "Numba and Numpy version are not equal" ? My numba version is 0.40.1 and my numpy version is 1.14.5.

    – lg53
    Nov 21 '18 at 9:11











  • Good tips for error_model="numpy", it let to treat without error case with eps=0. Thanks !

    – lg53
    Nov 21 '18 at 9:13











  • I meant that in case of a division by zero your Numba version raises an exception without setting error_model="numpy", while the numpy function doesn't. That can lead to unwanted behaviour.

    – max9111
    Nov 21 '18 at 9:23











  • ok, not equal in the meaning that not works identically. I understand, thanks.

    – lg53
    Nov 21 '18 at 14:52



















  • BTW: Your Numba and Numpy version are not equal. If a division by zero occurs the Numba version will act by default like Python and raise an exception. In Numpy a division by zero results in inf and you will see a Runtime Warning. If you write @nb.njit(cache=True,error_model="numpy") Numba will behave like Numpy, but without a runtime warning.

    – max9111
    Nov 20 '18 at 16:00











  • What do you mean by "Numba and Numpy version are not equal" ? My numba version is 0.40.1 and my numpy version is 1.14.5.

    – lg53
    Nov 21 '18 at 9:11











  • Good tips for error_model="numpy", it let to treat without error case with eps=0. Thanks !

    – lg53
    Nov 21 '18 at 9:13











  • I meant that in case of a division by zero your Numba version raises an exception without setting error_model="numpy", while the numpy function doesn't. That can lead to unwanted behaviour.

    – max9111
    Nov 21 '18 at 9:23











  • ok, not equal in the meaning that not works identically. I understand, thanks.

    – lg53
    Nov 21 '18 at 14:52

















BTW: Your Numba and Numpy version are not equal. If a division by zero occurs the Numba version will act by default like Python and raise an exception. In Numpy a division by zero results in inf and you will see a Runtime Warning. If you write @nb.njit(cache=True,error_model="numpy") Numba will behave like Numpy, but without a runtime warning.

– max9111
Nov 20 '18 at 16:00





BTW: Your Numba and Numpy version are not equal. If a division by zero occurs the Numba version will act by default like Python and raise an exception. In Numpy a division by zero results in inf and you will see a Runtime Warning. If you write @nb.njit(cache=True,error_model="numpy") Numba will behave like Numpy, but without a runtime warning.

– max9111
Nov 20 '18 at 16:00













What do you mean by "Numba and Numpy version are not equal" ? My numba version is 0.40.1 and my numpy version is 1.14.5.

– lg53
Nov 21 '18 at 9:11





What do you mean by "Numba and Numpy version are not equal" ? My numba version is 0.40.1 and my numpy version is 1.14.5.

– lg53
Nov 21 '18 at 9:11













Good tips for error_model="numpy", it let to treat without error case with eps=0. Thanks !

– lg53
Nov 21 '18 at 9:13





Good tips for error_model="numpy", it let to treat without error case with eps=0. Thanks !

– lg53
Nov 21 '18 at 9:13













I meant that in case of a division by zero your Numba version raises an exception without setting error_model="numpy", while the numpy function doesn't. That can lead to unwanted behaviour.

– max9111
Nov 21 '18 at 9:23





I meant that in case of a division by zero your Numba version raises an exception without setting error_model="numpy", while the numpy function doesn't. That can lead to unwanted behaviour.

– max9111
Nov 21 '18 at 9:23













ok, not equal in the meaning that not works identically. I understand, thanks.

– lg53
Nov 21 '18 at 14:52





ok, not equal in the meaning that not works identically. I understand, thanks.

– lg53
Nov 21 '18 at 14:52




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53389113%2fnumba-difference-between-first-time-execution-and-following-executions%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

鏡平學校

ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

Why https connections are so slow when debugging (stepping over) in Java?