8

Running Quit is a core task repeated many times in any debugging/development cycle. Its efficiency is therefore important and yet in my set-up it is taking somewhere between 4-10s to complete. This seems excessive. Why is it taking so long and what strategies can be employed to minimise this time?

I've observed the lower bound of 4s for a "clean" Quit, 8s when all my "init" packages are loaded and sometimes >10s following a long session. I also wonder by how much this varies from system-to-system and/or version-to-version? (timings above for V12.1.1, 2018 MacBook Pro, macOS 10.15.6).

Update As a benchmark to keep tabs on this timing, the following shows Launch and Quit times (in seconds) for both "Clean" (no packages loaded, no other notebooks open) and "PackagesLoaded" scenarios.

enter image description here

Hence the resolution of the above shows that the time to Quit is actually pretty consistent and reasonable irrespective of current state. Hence, anything beyond a 0.5s Quit time suggests an issue or perhaps is an indication that an automatic kernel has re-launched for some reason, possibly as catalogued in my answer.

Ronald Monson
  • 6,076
  • 26
  • 46
  • 1
    It probably comes from closing down threads, calling destructors, freeing resources etc. I do not work at Wolfram but based on my C++ experience I imagine it spends a lot of time closing things down and freeing memory. Since the kernel executable process ends on Quit[] anyway, there is little point to this - the OS will free that stuff much faster in bulk. The saying goes "don't clean the dishes as the building is being demolished". However, design-wise it's probably hard to avoid because calling destructors is also necessary to prevent memory leaks while the kernel is up and running. – flinty Aug 14 '20 at 15:19
  • I'm on 12.1.1.0 Windows 10 and I have to say I haven't noticed it go above 2s with both Rubi and Combinatorica loaded. Sometimes I haven't been able to quit the kernel at all this way because the front-end is locked up and no longer interactive, so I open the task manager and kill the Wolfram Kernel subprocess of Mathematica.exe directly - this is instantaneous and kills the kernel while keeping the front-end alive. – flinty Aug 14 '20 at 15:34
  • @flinty "don't clean the dishes as the building is being demolished" is a good way of putting my initial thoughts but I don't get the last sentence suggesting the dishes still needed cleaning? I guess the task-manager-kills not having any deleterious effects suggest the cleaning was not necessary? Also, can I ask, any noticeable difference between Quits having those two packages (un)loaded? – Ronald Monson Aug 14 '20 at 15:52
  • Yes, cleaning is not always necessary at termination - the OS will handle it, except in some ambiguous cases like closing ports / file locks. Freeing-resources is necessary during a program session though, so programmers will design for that case and this worsens termination performance. I'd have to profile a WolframKernel process during a quit to determine if this was the cause by looking for lots of hits on name-mangled C++ destructors. I cannot see any difference with those packages loaded / unloaded. If you have Apple's 'Instruments' installed you could profile it. – flinty Aug 14 '20 at 16:17
  • Perhaps you could share your init.m ? And how long does Quit[] take if your init.m is empty and you start from a blank notebook? – flinty Aug 14 '20 at 16:19
  • Do you get the slow quit if you do Evaluation > Quit Kernel, vs the Quit[] command ? If not, then see this answer which suggests to me you may still have something running in the evaluation queue. – flinty Aug 14 '20 at 16:36
  • Viewing my init.m probably wouldn't be that illuminating as it's a bit elaborate (50+ packages, linked to multiple subpackage and "DeclarePackage variables" in the hundreds. This complexity might suggest the higher timings (I may have to do some fine-grained testing) but on the other hand the lazy loading it pervasively implements should reduce the loading memory footprint while the "clean" Quit of 4s I mentioned is from a blank notebook without any init.m/Dynamics/$Epilog etc. – Ronald Monson Aug 14 '20 at 16:41
  • Yes, the menu Quit still seems slow (although harder to time) but what I've just noticed is that post-Quit evaluations are quick suggesting that my Quit is somehow also re-starting a kernel explaining the 2s doubling. Also, my "init" loading is being done by an $InitializationContexts setting. Look I'll stop now and I'd better go and try a few more things - thanks for your input - it has given me some ideas to test. – Ronald Monson Aug 14 '20 at 16:55

1 Answers1

9

There are conceivably numerous explanations but the immediate reason that (mostly) prompted this question took some tracking down so I'll record it here:

1. Setting of "ClearEvaluationQueueOnKernelQuit" option

I had inadvertently left this (undocumented) option set to

CurrentValue[$FrontEndSession,"ClearEvaluationQueueOnKernelQuit"] = False

when tinkering with the answer to the question of how to Quit the Kernel and start new session automatically. The question involved doing this automatic re-starting via a button and hence the answer's False setting of this option was only temporary. Hence that answer shouldn't introduce the persistent False setting above that caused this behaviour.

With this option set to False the 4s Quit time involves a new kernel restarting. With it returned to the default True a "clean" Quittakes a more familiar ~0.5s with subsequent "clean" launches a more familiar ~1s.

2. A setting in $UserBaseDirectory/FrontEnd/init.m

This is where "ClearEvaluationQueueOnKernelQuit" is stored which might be non-obvious when hunting for kernel issues (it doesn't, for example, appear on any of CurrentValue[$FrontEnd,AutoloadPath]). It also contains a lot of settings that build-up over time some of which may be candidates for causing any excessive timings.

3. A Dynamic in some open notebook

These can quietly launch kernels after Quit is run making the Quit time seem longer than it actually is.

Ronald Monson
  • 6,076
  • 26
  • 46
  • I'm glad you finally got to the bottom of it and posted this. – flinty Aug 15 '20 at 12:47
  • @flinty So am I! You were right to suspect the evaluation queue which may have triggered a memory for tracking this down. Thanks. It turns out then, that no great "dish-cleaning" actually does take place in a Quit but the other take-away is a bit more galling -- programmers really ought to practice good coding hygiene when tinkering by re-setting default values - especially when they involve non-documented features and especially when they occur in non-normal control flows! – Ronald Monson Aug 16 '20 at 05:12