startup: Print GC information #138
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Now, we can get some idea for what is happening when Emacs is starting up. Here we don't actually print any information about the *time* spent in GC, but we do get an idea for the number of GCs done. The Emacs garbage collector operates by finding and "marking" all Lisp objects that are still accessible to Lisp programs. It assumes that all symbols and their associated values and function definitions, and things present on the stack are accessible. Then any objects reachable through these presumed-accessible objects are also considered accessible. After the process of markinging accessible Lisp objects is done, those left unmarked are garbage, and cannot be reached by normal means. It can be quite helpful to know how many GC operationss were performed during startup to see if the GC parameters are set properly. On my system, for example, the gc-cons-threshold is merely 800_000 bytes (800 KB). This is the default for 64-bit systems, but results in 42 GC sweeps being performed during startup, which take a non-trivial amount of time. Signed-off-by: Kristofer Rye <[email protected]>
I think this is probably very useful for us to have in addition to the gcs-done printout. Signed-off-by: Kristofer Rye <[email protected]>
This makes it fit better on the screen, while still conveying the same amount of information. Signed-off-by: Kristofer Rye <[email protected]>
We don't really need to know how much time is spent in GC down to the
microsecond. Milliseconds (10^{-3}s) should be plenty of precision, as
the user can always go and inspect gc-elapsed as they please.
Signed-off-by: Kristofer Rye <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Because we (currently) use an interesting hodgepodge of sync and async loading during startup, I think it might be useful to convey to the user some information about how much garbage collection occurred during startup. Loading things (processing functions, strings, etc., and just general startup work) will necessarily produce garbage to be swept, and so it might be helpful to know just how much is happening during our init sweep.
This PR adds a small printout of the number of GC sweeps and the amount of time spent doing GC during startup. The
initial-scratch-messageis populated by theafter-init-hookwhich means the readout should capture all the GC data.I've had success in reducing the number of GCs by bumping up
gc-cons-thresholdand fiddling withgc-cons-percentage, but it's nice to be able to get a grasp on where we're at right now.One possible change I could make is to gate this behind a variable. Note that both
gcs-doneandgc-elapsedare variables that are populated by Emacs' C code inalloc.c, so this doesn't add much overhead besides a few more strings in the concat call and the two calls toformat.