> My test case constructed ten thousand times a list of size 1000, > triggering a lot of garbage collections. In a freshly started Emacs, > the ring-elements function I propose to install ran the test in 11 > seconds, slightly over 5 being spent in gc. This gives between 5 and > 6 for the function itself. The "abstract" version ran 37 seconds, a > little bit over 5 in gc, giving 31 to 32 for the function itself. In > other words, avoiding the `ring-ref' overhead makes the function run > more than five times faster, but the amount of consing stays the same. > > If I run the same test in a somewhat older Emacs, the functions > themselves still take 5 to 6 and 31 to 32 seconds, but now they both > spend 17.5 seconds doing gc (instead of slightly more than 5). > > I guess that in a really big Emacs, gc will take even much longer. It > is not very surprising that the more objects gc has to check, the > longer it takes. I believe this pretty much explains the gradual > slowdown of Emacs as it grows older (and hence bigger).
Yes, indeed GC is what causes the slowdown. With the option `garbage-collection-messages' set to t, it is clearly visible that in a big Emacs session GC takes too much time. For example, I can see that each GC takes about 1 sec. The formula (/ gc-elapsed gcs-done) with real values (/ 1788.2 1597) gives 1.12 sec. This is substantial time for every GC to contribute to the overall slowdown. -- Juri Linkov http://www.jurta.org/emacs/ _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
