# Why does it take so long to Quit?

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.

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.

• 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. Aug 14, 2020 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. Aug 14, 2020 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? Aug 14, 2020 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. Aug 14, 2020 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? Aug 14, 2020 at 16:19

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

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.
These can quietly launch kernels after Quit is run making the Quit time seem longer than it actually is.
• @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! Aug 16, 2020 at 5:12