Why does starting a process in VS Debugger take a much longer time on the first run?
I am evaluating the performance of a program written in C# that calls an external python program. I'm using the stopwatch to compare the performance
var watch = System.Diagnostics.Stopwatch.StartNew();
//code...
watch.Stop();
var elapsedMs = watch.ElapsedMilliseconds;
The external Python program is called using:
Process.Start(start)
The first time I execute it under a debugger I get around 17-26 elapsed seconds. The next time I execute it, I get 700 ms. If I restart the computer, and rerun the test, I would get a time elapsed in the range of 17-26 seconds. Am I correct in assuming that after the first Debug, Visual studio keeps the process in the memory and that way speeds up the execution, even though I stopped the Debugging. I've checked the task manager if "python" was running, but didn't see an entry for it between runs.
c# .net process
add a comment |
I am evaluating the performance of a program written in C# that calls an external python program. I'm using the stopwatch to compare the performance
var watch = System.Diagnostics.Stopwatch.StartNew();
//code...
watch.Stop();
var elapsedMs = watch.ElapsedMilliseconds;
The external Python program is called using:
Process.Start(start)
The first time I execute it under a debugger I get around 17-26 elapsed seconds. The next time I execute it, I get 700 ms. If I restart the computer, and rerun the test, I would get a time elapsed in the range of 17-26 seconds. Am I correct in assuming that after the first Debug, Visual studio keeps the process in the memory and that way speeds up the execution, even though I stopped the Debugging. I've checked the task manager if "python" was running, but didn't see an entry for it between runs.
c# .net process
1
That is not correct. The sub-process is independent of VS and is not kept in memory. There are, however, other bits of the system outside of VS.. what is the behavior when running the same program in say, a shell?
– user2864740
Nov 28 '18 at 0:32
Are you resetting the Stopwatch? If not, it will continue where it left off last time.
– Jon Vote
Nov 28 '18 at 0:33
@JonVote First run is 17-26 seconds, second run is 700ms.
– user2864740
Nov 28 '18 at 0:34
1
Visual studio keeps the process in the memory Not VS but system can ... also python may recompile your script first time
– Selvin
Nov 28 '18 at 0:35
@user2864740 I tried running it outside the .NET environment and just using the command line with a python profiler: python -m cProfile file.py arguments And observed the same behaviour. So .NET doesn't have anything to do with it. The first time I run the python program it takes a very long time >20 seconds. The next execution is much faster. The python program reads a list of variables from a file and then fits it to a plynomial curve using the scipy library.
– alexibbb
Nov 28 '18 at 0:46
add a comment |
I am evaluating the performance of a program written in C# that calls an external python program. I'm using the stopwatch to compare the performance
var watch = System.Diagnostics.Stopwatch.StartNew();
//code...
watch.Stop();
var elapsedMs = watch.ElapsedMilliseconds;
The external Python program is called using:
Process.Start(start)
The first time I execute it under a debugger I get around 17-26 elapsed seconds. The next time I execute it, I get 700 ms. If I restart the computer, and rerun the test, I would get a time elapsed in the range of 17-26 seconds. Am I correct in assuming that after the first Debug, Visual studio keeps the process in the memory and that way speeds up the execution, even though I stopped the Debugging. I've checked the task manager if "python" was running, but didn't see an entry for it between runs.
c# .net process
I am evaluating the performance of a program written in C# that calls an external python program. I'm using the stopwatch to compare the performance
var watch = System.Diagnostics.Stopwatch.StartNew();
//code...
watch.Stop();
var elapsedMs = watch.ElapsedMilliseconds;
The external Python program is called using:
Process.Start(start)
The first time I execute it under a debugger I get around 17-26 elapsed seconds. The next time I execute it, I get 700 ms. If I restart the computer, and rerun the test, I would get a time elapsed in the range of 17-26 seconds. Am I correct in assuming that after the first Debug, Visual studio keeps the process in the memory and that way speeds up the execution, even though I stopped the Debugging. I've checked the task manager if "python" was running, but didn't see an entry for it between runs.
c# .net process
c# .net process
edited Nov 28 '18 at 0:33
user2864740
44.1k671149
44.1k671149
asked Nov 28 '18 at 0:30
alexibbbalexibbb
286
286
1
That is not correct. The sub-process is independent of VS and is not kept in memory. There are, however, other bits of the system outside of VS.. what is the behavior when running the same program in say, a shell?
– user2864740
Nov 28 '18 at 0:32
Are you resetting the Stopwatch? If not, it will continue where it left off last time.
– Jon Vote
Nov 28 '18 at 0:33
@JonVote First run is 17-26 seconds, second run is 700ms.
– user2864740
Nov 28 '18 at 0:34
1
Visual studio keeps the process in the memory Not VS but system can ... also python may recompile your script first time
– Selvin
Nov 28 '18 at 0:35
@user2864740 I tried running it outside the .NET environment and just using the command line with a python profiler: python -m cProfile file.py arguments And observed the same behaviour. So .NET doesn't have anything to do with it. The first time I run the python program it takes a very long time >20 seconds. The next execution is much faster. The python program reads a list of variables from a file and then fits it to a plynomial curve using the scipy library.
– alexibbb
Nov 28 '18 at 0:46
add a comment |
1
That is not correct. The sub-process is independent of VS and is not kept in memory. There are, however, other bits of the system outside of VS.. what is the behavior when running the same program in say, a shell?
– user2864740
Nov 28 '18 at 0:32
Are you resetting the Stopwatch? If not, it will continue where it left off last time.
– Jon Vote
Nov 28 '18 at 0:33
@JonVote First run is 17-26 seconds, second run is 700ms.
– user2864740
Nov 28 '18 at 0:34
1
Visual studio keeps the process in the memory Not VS but system can ... also python may recompile your script first time
– Selvin
Nov 28 '18 at 0:35
@user2864740 I tried running it outside the .NET environment and just using the command line with a python profiler: python -m cProfile file.py arguments And observed the same behaviour. So .NET doesn't have anything to do with it. The first time I run the python program it takes a very long time >20 seconds. The next execution is much faster. The python program reads a list of variables from a file and then fits it to a plynomial curve using the scipy library.
– alexibbb
Nov 28 '18 at 0:46
1
1
That is not correct. The sub-process is independent of VS and is not kept in memory. There are, however, other bits of the system outside of VS.. what is the behavior when running the same program in say, a shell?
– user2864740
Nov 28 '18 at 0:32
That is not correct. The sub-process is independent of VS and is not kept in memory. There are, however, other bits of the system outside of VS.. what is the behavior when running the same program in say, a shell?
– user2864740
Nov 28 '18 at 0:32
Are you resetting the Stopwatch? If not, it will continue where it left off last time.
– Jon Vote
Nov 28 '18 at 0:33
Are you resetting the Stopwatch? If not, it will continue where it left off last time.
– Jon Vote
Nov 28 '18 at 0:33
@JonVote First run is 17-26 seconds, second run is 700ms.
– user2864740
Nov 28 '18 at 0:34
@JonVote First run is 17-26 seconds, second run is 700ms.
– user2864740
Nov 28 '18 at 0:34
1
1
Visual studio keeps the process in the memory Not VS but system can ... also python may recompile your script first time
– Selvin
Nov 28 '18 at 0:35
Visual studio keeps the process in the memory Not VS but system can ... also python may recompile your script first time
– Selvin
Nov 28 '18 at 0:35
@user2864740 I tried running it outside the .NET environment and just using the command line with a python profiler: python -m cProfile file.py arguments And observed the same behaviour. So .NET doesn't have anything to do with it. The first time I run the python program it takes a very long time >20 seconds. The next execution is much faster. The python program reads a list of variables from a file and then fits it to a plynomial curve using the scipy library.
– alexibbb
Nov 28 '18 at 0:46
@user2864740 I tried running it outside the .NET environment and just using the command line with a python profiler: python -m cProfile file.py arguments And observed the same behaviour. So .NET doesn't have anything to do with it. The first time I run the python program it takes a very long time >20 seconds. The next execution is much faster. The python program reads a list of variables from a file and then fits it to a plynomial curve using the scipy library.
– alexibbb
Nov 28 '18 at 0:46
add a comment |
0
active
oldest
votes
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53510339%2fwhy-does-starting-a-process-in-vs-debugger-take-a-much-longer-time-on-the-first%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53510339%2fwhy-does-starting-a-process-in-vs-debugger-take-a-much-longer-time-on-the-first%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
1
That is not correct. The sub-process is independent of VS and is not kept in memory. There are, however, other bits of the system outside of VS.. what is the behavior when running the same program in say, a shell?
– user2864740
Nov 28 '18 at 0:32
Are you resetting the Stopwatch? If not, it will continue where it left off last time.
– Jon Vote
Nov 28 '18 at 0:33
@JonVote First run is 17-26 seconds, second run is 700ms.
– user2864740
Nov 28 '18 at 0:34
1
Visual studio keeps the process in the memory Not VS but system can ... also python may recompile your script first time
– Selvin
Nov 28 '18 at 0:35
@user2864740 I tried running it outside the .NET environment and just using the command line with a python profiler: python -m cProfile file.py arguments And observed the same behaviour. So .NET doesn't have anything to do with it. The first time I run the python program it takes a very long time >20 seconds. The next execution is much faster. The python program reads a list of variables from a file and then fits it to a plynomial curve using the scipy library.
– alexibbb
Nov 28 '18 at 0:46