Both @darthrupert and @natyrys on the thread have said most of what I know. It's a little machine dependent to get the true sweet spot, but raising it from the like, megabyte (slight hyperbole) or whatever that it defaults to is the 80/20.

i got annoyed by emacs gc pauses and just disabled the gc completely (i think). haven't noticed any downsides so far. i'm in emacs all day...

    ;; don't garbage collect based on cons count
    (setq gc-cons-threshold 10000000000)
    (defun garbage-collect (&rest args)
     (message "trying to garbage collect. probably you want to quit emacs."))

something i love about emacs is everything is implemented in the same abstraction (of a "buffer of text"). so i can manipulate and move around an embedded terminal in the same way as a normal file, etc.

playing briefly with Zed it seemed like the terminal was a totally different "thing" than a normal file; i couldn't run the same text selection operations, couldn't split the window vertically or horizontally, etc. to me that loses a ton of the benefit of having a terminal in the editor in the first place.

still, it's a very interesting project. i have a very love/hate relationship with emacs, so i'm always interested in alternatives...

Ripped from my .emacs:

    (setq gc-cons-threshold (\* 100 1024 1024) ;; GC sometime after allocating 100Mb 
          read-process-output-max (\* 1024 1024)
          company-idle-delay 0.0 ;; company completions should be fast
          company-minimum-prefix-length 1
          lsp-idle-delay 0.1)  ;; clangd is fast
    (run-with-idle-timer 2 t (lambda () (garbage-collect))) ;; Trigger a GC after 5s of idle time

This is something of a hack of course, but it works & memory is cheap. You might want to push the GC threshold back down after emacs startup - a GC that fires early is a GC that does less work per invocation & is therefore less likely to cause perceptible stutter.