Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

[Stefan Monnier]

> +	(free_cons, free_misc): Subtract object size from consing_since_gc.

Why bother?


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

[Dmitry Antipov]

On 07/23/2012 12:58 PM, Stefan Monnier wrote:

>> +	(free_cons, free_misc): Subtract object size from consing_since_gc.
>
> Why bother?

IMHO, mostly because consing_since_gc means "total size of new objects which
are managed by GC". If we manage some of them by hand, we shouldn't allow GC
to overestimate an amount of work to be done.

Dmitry

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

[Stefan Monnier]

>>> +	(free_cons, free_misc): Subtract object size from consing_since_gc.
>> Why bother?
> IMHO, mostly because consing_since_gc means "total size of new objects which
> are managed by GC". If we manage some of them by hand, we shouldn't allow GC
> to overestimate an amount of work to be done.

So, it's only for theoretical reasons?
If so, I'd rather we don't bother.


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

[Dmitry Antipov]

On 07/23/2012 02:06 PM, Stefan Monnier wrote:

>> IMHO, mostly because consing_since_gc means "total size of new objects which
>> are managed by GC". If we manage some of them by hand, we shouldn't allow GC
>> to overestimate an amount of work to be done.
>
> So, it's only for theoretical reasons?
> If so, I'd rather we don't bother.

Hm... not so theoretical. For example, this really helps, especially when editing
huge fontified buffers (not sure that this is 100% correct, BTW):

=== modified file 'src/editfns.c'
--- src/editfns.c	2012-07-17 07:43:01 +0000
+++ src/editfns.c	2012-07-23 11:20:02 +0000
@@ -3379,6 +3379,10 @@

  	  buf->clip_changed = 1; /* Remember that the narrowing changed. */
  	}
+      /* These aren't needed anymore, so don't wait for GC.  */
+      free_marker (XCAR (data));
+      free_marker (XCDR (data));
+      free_cons (XCONS (data));
      }
    else
      /* A buffer, which means that there was no old restriction.  */

Dmitry

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

[Stefan Monnier]

>>> IMHO, mostly because consing_since_gc means "total size of new
>>> objects which are managed by GC". If we manage some of them by hand,
>>> we shouldn't allow GC to overestimate an amount of work to be done.
>> 
>> So, it's only for theoretical reasons?
>> If so, I'd rather we don't bother.

> Hm... not so theoretical. For example, this really helps, especially
> when editing huge fontified buffers (not sure that this is 100%
> correct, BTW):

What helps?  Adding those calls to free_marker, or adding the "decrement
consing_since_gc in free_marker"?  I can believe the first, but I doubt
the second will make much of a difference.


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

[Dmitry Antipov]

On 07/24/2012 03:11 AM, Stefan Monnier wrote:

> What helps?  Adding those calls to free_marker, or adding the "decrement
> consing_since_gc in free_marker"?  I can believe the first, but I doubt
> the second will make much of a difference.

Local: both conses and markers are allocated very often, and explicitly freed ones
most probably will be re-used again very soon, at the cost of link to/unlink from
the free lists, thus avoiding possible new block allocation.

Global: Ideal GC manages an infinite amount of memory so the collection is never
started. For the real cases, some time periods are more advisable for running GC
(when we're idle, for example); but, since we can't predict when "more advisable"
time comes, it's the best bet to run GC as later as possible for the same amount
of work.

Dmitry

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

[Stefan Monnier]

>> What helps?  Adding those calls to free_marker, or adding the "decrement
>> consing_since_gc in free_marker"?  I can believe the first, but I doubt
>> the second will make much of a difference.
> Local: both conses and markers are allocated very often, and
> explicitly freed ones most probably will be re-used again very soon,
> at the cost of link to/unlink from the free lists, thus avoiding
> possible new block allocation.
> Global: Ideal GC manages an infinite amount of memory so the
> collection is never started. For the real cases, some time periods are
> more advisable for running GC (when we're idle, for example); but,
> since we can't predict when "more advisable" time comes, it's the best
> bet to run GC as later as possible for the same amount of work.

I do not understand how that answers my question.
So to repeat: do you claim that "decrement consing_since_gc in
free_marker" helps performance?  If so, do you have concrete
measurements showing it?


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

[Dmitry Antipov]

On 07/24/2012 01:11 PM, Stefan Monnier wrote:

> I do not understand how that answers my question.
> So to repeat: do you claim that "decrement consing_since_gc in
> free_marker" helps performance?  If so, do you have concrete
> measurements showing it?

With save-restriction patch sent at
http://lists.gnu.org/archive/html/emacs-devel/2012-07/msg00484.html,
is saves ~40 GCs in my "scroll over xdisp.c" test.

Dmitry

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

[Stefan Monnier]

>> I do not understand how that answers my question.
>> So to repeat: do you claim that "decrement consing_since_gc in
>> free_marker" helps performance?  If so, do you have concrete
>> measurements showing it?
> With save-restriction patch sent at
> http://lists.gnu.org/archive/html/emacs-devel/2012-07/msg00484.html,
> is saves ~40 GCs in my "scroll over xdisp.c" test.

What about the overall running time.  How much is saved by your patch,
and how much additional is saved by the "decrement consing_since_gc in
free_marker"?


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

[Dmitry Antipov]

On 07/25/2012 01:59 AM, Stefan Monnier wrote:

> What about the overall running time.  How much is saved by your patch,
> and how much additional is saved by the "decrement consing_since_gc in
> free_marker"?

Hm. The test is:

(defun scroll-benchmark ()
   (interactive)
   (let ((oldgc gcs-done)
	(oldtime (float-time)))
     (condition-case nil (while t (scroll-up) (redisplay))
       (error (message "GCs: %d Elapsed time: %f seconds"
		      (- gcs-done oldgc) (- (float-time) oldtime))))))

For xdisp.c, the original results are 600 GCs and 32.65 seconds.

When free_cons and free_misc subtracts from consing_since_gc,
and save_restriction_restore frees it's data explicitly, results
are 560 GCs and 31.95 seconds.

Of course, explicit free in  save_restriction_restore makes no sense
if we fool GC with consing_since_gc: 600 GCs and 32.95 seconds.

I don't understand why we're still wast^W^Wspending our time with
such a simple and almost obvious thing.

Dmitry

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

[Stefan Monnier]

> For xdisp.c, the original results are 600 GCs and 32.65 seconds.

> When free_cons and free_misc subtracts from consing_since_gc,
> and save_restriction_restore frees it's data explicitly, results
> are 560 GCs and 31.95 seconds.

> Of course, explicit free in  save_restriction_restore makes no sense
> if we fool GC with consing_since_gc: 600 GCs and 32.95 seconds.

I see.  I didn't expect that reducing memory use would be so
little difference.  Thanks for giving the details.

> I don't understand why we're still wast^W^Wspending our time with
> such a simple and almost obvious thing.

Because it went against my intuition.


        Stefan

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109187: Adjust consing_since_gc when objects are explicitly freed.

[Stephen J. Turnbull]

Dmitry Antipov writes:

 > IMHO, mostly because consing_since_gc means "total size of new objects which
 > are managed by GC". If we manage some of them by hand, we shouldn't allow GC
 > to overestimate an amount of work to be done.

Why is it an overestimate of the work to be done?  AFAIK, these
objects come from the same pools, and they are not necessarily short-
lived in the sense that they are allocated and deallocated before
other objects become allocated.  If my assumption about the memory
pools is correct, a no-see-um cons is just as likely to overflow a
pool, and somewhat likely to contribute to overflow of later
allocations.  If it's a container and live when GC occurs, it will
need to be traversed.  So it does contribute to the work to be done,
although not as likely to contribute as GC-managed objects are.