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

Guess what letter conforming each word

Port of Spain

Run scheduled task as local user group (not BUILTIN)