Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109157: Compact buffers when idle.

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> I can't think of any case where that would provide any noticeable
>> benefit (whereas I can think of cases where it just wastes resources).
> Hm... I expect this to be something exotic, like replace-string
> across hundreds of buffers. On the other side, it's quite
> typical code refactoring operation. When I need to change function
> name across the project, I'm using perl just because Emacs is too slow :-(.

I see no evidence that calling compact-buffers from an idle timer will
make any difference to this scenario.

>> The GC is run fairly regularly, also typically while idle, and does the
>> compaction.
> 1. Typically it happens when we're executing byte code, or from eval.c,
>    when we want to be as fast as possible.

Again, I don't see how calling compact-buffers from an idle timer will
make any difference to this case.  BTW, while running the GC in those
cases may be a very visible operation, it's not necessarily inefficient
(unless you consider the usual calls to `free' in non-GC languages as
a unneeded inefficiency), it's just that freeing memory is part of the
needed work and we simply allocated too much memory to be able to
postpone this work to some idle time.

> 2. I don't understand why idle call to Fgarbage_collect is glued with
>    auto-save-timeout. If I don't want to use auto-save, why I shouldn't
>    call GC when idle?

I don't know, probably because it was simpler that way.  Feel free to
propose changes in this area.  Again, I don't see how that is relevant
to calling compact-buffers from an idle timer.

>> So until you can provide some concrete and convincing numbers that show
>> some benefit, I'd ask you to remove that pat of your patch.
> Hm... I suppose that 3GHz CPUs makes a lot of small optimizations almost
> invisible; but I believe it doesn't mean that they're not needed anymore.

I'm not opposed to optimizations, but I do want to first see evidence
that it is indeed an optimization and not a pessimization.

Also note that we're not talking removing some optimization that was
needed back then, but about adding a new optimization, even though it
hasn't seemed to be needed for the last 25 years, hence the higher
requirements.


        Stefan