I have a large repository for solving a dynamic economic model with heterogeneous agents.
The code takes about 400 seconds to run when running Julia from the command prompt, but only about 240 seconds when running in VSCode.
When timing, a noticeable discrepancy is the amount of time spent doing garbage collection. In VSCode, it’s around 15%. From the command prompt, it’s about 40%.
I know that a minimal working example would be helpful but it’s hard to know where to begin with that since the code base is quite large, lots of functions, iteration, etc.
I thought I might check to see if this is a known issue.
If not, I’ll try doing some profiling to see if I can track down which functions are substantially slower in the command prompt than in VSCode.
Thanks in advance!
The only reason I can think of is the default number of threads being different in VSCode, is that the case?
I don’t think it is. I always start julia in the command line with 8 threads and using the Threads.nthreads()
gives the same result.
I thought it might be a discrepancy between running scripts from the REPL (via command line) vs noninteractive execution but timings are similar.
Somehow I think the difference in garbage collection time must be what is causing the speed differences but I can’t think of a reason why that should differ.
Wait what do you mean by “command prompt”? Running things like julia myfile.jl
? In that case, the startup time is expected to be much worse (albeit better in 1.9), that’s why the typical dev workflow in Julia is interactive
I’ve ignored the startup time. In both cases, I let julia get going (e.g., load in packages, etc.). Then the last line of my script is @time function()
. Where function()
wraps many iterations of a bunch of other functions (i.e., such that compliation time should be a minimal factor).
For the command prompt, I’m using the windows command prompt (“cmd”). Then I startup the julia REPL and run the script with an include("script.jl")
command.
So the timings are based on the results of the @time
call.
1 Like
Turns out this is in fact nothign to do with running in VSCode versus command prompt. Instead, I had executed a different function first when using VSCode. And for some reason, the performance of the function I am interested in is dramatically improved after running this other unrelated function.
That’s still a big mystery, but I’m going to end this post and start a new one for that.
1 Like