Default history-length should be higher

Default history-length should be higher

[Tom]

I checked the sources and apparently history-length default 
is still 30. It may have been a good default 20 years ago,
but in the 2010s it could be higher.

savehist and other packages can save the histories and it is very
useful to have access to a bunch of past history entries
which are easy to browse with the various history completion
packages.

Wouldn't 100 be a better default for history-length?

Re: Default history-length should be higher

[Stefan Monnier]

> Wouldn't 100 be a better default for history-length?

No objection from me,


        Stefan

RE: Default history-length should be higher

[Drew Adams]

> > Wouldn't 100 be a better default for history-length?
> 
> No objection from me,

FWIW, I use 1000.  Any reason this should be as short as 100?

Re: Default history-length should be higher

[Tom]

Drew Adams <drew.adams <at> oracle.com> writes:

> 
> > > Wouldn't 100 be a better default for history-length?
> > 
> > No objection from me,
> 
> FWIW, I use 1000.  Any reason this should be as short as 100?
> 

I use 1000 too in my personal setup and it works fine for me. 

I only said 100, because I was not sure the powers that be would
not find 1000 to radical, but I agree 1000 is an even better
default.

RE: Default history-length should be higher

[Drew Adams]

> > > > Wouldn't 100 be a better default for history-length?
> > >
> > > No objection from me,
> >
> > FWIW, I use 1000.  Any reason this should be as short as 100?
> 
> I use 1000 too in my personal setup and it works fine for me.
> 
> I only said 100, because I was not sure the powers that be would
> not find 1000 to radical, but I agree 1000 is an even better
> default.

BTW, whether someone finds a history list of 1000 elements to be
long or reasonable might also have to do with how they access its
elements.

If someone typically just cycles among elements using, say, `M-p',
instead of searching (using, say, `M-r') or completing, then 1000
would generally be far too long a list - as would even 100 probably.
(I tend to complete against the history list.)

Re: Default history-length should be higher

[Tom]

Drew Adams <drew.adams <at> oracle.com> writes:
> 
> BTW, whether someone finds a history list of 1000 elements to be
> long or reasonable might also have to do with how they access its
> elements.
> 
> If someone typically just cycles among elements using, say, `M-p',
> instead of searching (using, say, `M-r') or completing, then 1000
> would generally be far too long a list - as would even 100 probably.
> (I tend to complete against the history list.)

All users should know at least M-r, it's in the manual, so it 
should be no argument against a longer history list.

Re: Default history-length should be higher

[Tom]

Tom <adatgyujto <at> gmail.com> writes:
> 
> All users should know at least M-r, it's in the manual, so it 
> should be no argument against a longer history list.
> 

I checked the manual to make sure and I also learned that isearch can 
be used to search the history which was new for me.

One always learns new things with emacs and isearch seems a quite
efficent way to search through a longer history:


   If an incremental search fails in the minibuffer, it tries searching
the minibuffer history.  *Note Minibuffer History::.  You can visualize
the minibuffer and its history as a series of "pages", with the
earliest history element on the first page and the current minibuffer
on the last page.  A forward search, `C-s', searches forward to later
pages; a reverse search, `C-r', searches backwards to earlier pages.
Like in ordinary buffer search, a failing search can wrap around, going
from the last page to the first page or vice versa.

RE: Default history-length should be higher

[Drew Adams]

> > BTW, whether someone finds a history list of 1000 elements to be
> > long or reasonable might also have to do with how they access its
> > elements.
> >
> > If someone typically just cycles among elements using, say, `M-p',
> > instead of searching (using, say, `M-r') or completing, then 1000
> > would generally be far too long a list - as would even 100 probably.
> > (I tend to complete against the history list.)
> 
> All users should know at least M-r, it's in the manual, so it
> should be no argument against a longer history list.

I didn't mention it as an argument against a longer history list
(of which I am in favor).  My point was that what is long for one
person might be short for another person, depending on how they
typically access the history.

The mere fact that `M-r' is documented does not mean that user X
makes much use of it.  Some people are cycling drones.

Re: Default history-length should be higher

[Michael Welsh Duggan]

Tom <adatgyujto@gmail.com> writes:

> Drew Adams <drew.adams <at> oracle.com> writes:
>> 
>> BTW, whether someone finds a history list of 1000 elements to be
>> long or reasonable might also have to do with how they access its
>> elements.
>> 
>> If someone typically just cycles among elements using, say, `M-p',
>> instead of searching (using, say, `M-r') or completing, then 1000
>> would generally be far too long a list - as would even 100 probably.
>> (I tend to complete against the history list.)
>
> All users should know at least M-r, it's in the manual, so it 
> should be no argument against a longer history list.

FWIW, I've been using emacs for many, many years, and did not know about
M-r.  On the other hand, I don't object to increasing the history size,
because now I know about M-r!  Thanks!

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Default history-length should be higher

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

While we're at it - why not increase the default `gc-cons-threshold' as
well. Currently the default is 0.8 MB, which seems super-conservative given
today most computers have 1GB+ of memory. Code that creates a lot of
objects would obviously be impacted significantly, since GC would be
performed frequently. Setting it to something in between 10MB and 50MB
seems much more reasonable to me.


On 26 January 2014 07:00, Michael Welsh Duggan <mwd@md5i.com> wrote:

> Tom <adatgyujto@gmail.com> writes:
>
> > Drew Adams <drew.adams <at> oracle.com> writes:
> >>
> >> BTW, whether someone finds a history list of 1000 elements to be
> >> long or reasonable might also have to do with how they access its
> >> elements.
> >>
> >> If someone typically just cycles among elements using, say, `M-p',
> >> instead of searching (using, say, `M-r') or completing, then 1000
> >> would generally be far too long a list - as would even 100 probably.
> >> (I tend to complete against the history list.)
> >
> > All users should know at least M-r, it's in the manual, so it
> > should be no argument against a longer history list.
>
> FWIW, I've been using emacs for many, many years, and did not know about
> M-r.  On the other hand, I don't object to increasing the history size,
> because now I know about M-r!  Thanks!
>
> --
> Michael Welsh Duggan
> (md5i@md5i.com)
>
>

[-- Attachment #2: Type: text/html, Size: 2074 bytes --]

Re: Default history-length should be higher

[Eli Zaretskii]

> Date: Sun, 26 Jan 2014 21:22:37 +0200
> From: Bozhidar Batsov <bozhidar@batsov.com>
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> While we're at it - why not increase the default `gc-cons-threshold' as
> well. Currently the default is 0.8 MB, which seems super-conservative given
> today most computers have 1GB+ of memory. Code that creates a lot of
> objects would obviously be impacted significantly, since GC would be
> performed frequently. Setting it to something in between 10MB and 50MB
> seems much more reasonable to me.

Did you try that?  If not, please do.  In my experience, your
suggestion has a downside: the GC indeed happens less frequently, but
when it does, it takes an annoyingly long time.  I find it easier to
tolerate many GCs that run to completion in less than a second, than
to have a few GCs that take several seconds each.

Re: Default history-length should be higher

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

On 26 January 2014 21:44, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 26 Jan 2014 21:22:37 +0200
> > From: Bozhidar Batsov <bozhidar@batsov.com>
> > Cc: emacs-devel <emacs-devel@gnu.org>
> >
> > While we're at it - why not increase the default `gc-cons-threshold' as
> > well. Currently the default is 0.8 MB, which seems super-conservative
> given
> > today most computers have 1GB+ of memory. Code that creates a lot of
> > objects would obviously be impacted significantly, since GC would be
> > performed frequently. Setting it to something in between 10MB and 50MB
> > seems much more reasonable to me.
>
> Did you try that?  If not, please do.  In my experience, your
> suggestion has a downside: the GC indeed happens less frequently, but
> when it does, it takes an annoyingly long time.  I find it easier to
> tolerate many GCs that run to completion in less than a second, than
> to have a few GCs that take several seconds each.
>

I've tested the flx package https://github.com/lewang/flx suggestion to
bump the gc-threshold and
the package definitely started working noticeably faster.  I haven't
noticed particularly long GC pauses.
Hopefully when multi-thread support is implemented in a future version of
Emacs we'll get some parallel GC as well.

[-- Attachment #2: Type: text/html, Size: 1926 bytes --]

Re: Default history-length should be higher

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> Did you try that?  If not, please do.  In my experience, your
> suggestion has a downside: the GC indeed happens less frequently, but
> when it does, it takes an annoyingly long time.  I find it easier to
> tolerate many GCs that run to completion in less than a second, than
> to have a few GCs that take several seconds each.

A bit of VC speleology showed this:

eb6a66b5 src/alloc.c  (Richard M. Stallman 1995-07-19 03:39:43 +0000 6734)   gc_cons_threshold = 100000 * sizeof (Lisp_Object);

So the current value of gc_cons_threshold comes from 1995. Today's
low-end machines are several times faster than high-end workstations at
that time.

So maybe it is worth experimenting with higher values. I'll do like
Bozhidar Batsov and set gc-cons-threshold to some large value and see
how it goes. I'm a flx user too.

RE: Default history-length should be higher

[Drew Adams]

> So maybe it is worth experimenting with higher values. I'll do like
> Bozhidar Batsov and set gc-cons-threshold to some large value and
> see how it goes. I'm a flx user too.

Experimenting is a good idea.
FWIW, I've used this value for years: 1600000

Re: Default history-length should be higher

[Trent W. Buck]

Bozhidar Batsov <bozhidar@batsov.com> writes:

> Setting it to something in between 10MB and 50MB seems much more
> reasonable to me.

I'd prefer a round number like 8MiB or 64MiB :-)

Re: Default history-length should be higher

[Stefan Monnier]

> Code that creates a lot of objects would obviously be impacted
> significantly, since GC would be performed frequently.

C-h v gc- TAB will show you that gc-cons-threshold is only one part of
the story.  As soon as the heap grows, gc-cons-percentage takes over.
I.e. by default, if your heap is 100MB big, GC will take place every
10MB (rather than every 0.8MB) of allocation.

Of course, maybe we should increase gc-cons-percentage.  But part of the
reason for wanting frequent GCs is to try and mitigate the effects
of fragmentation.  So, a higher gc-cons-threshold might speed up
initialization of `flx' but it might also cause your Emacs session to
use more VSZ and RSS, which will also tend to make each GC slower.

In reality for code that just allocates a large data-structure and not
much else, the best option is "never GC" (since every GC will just waste
time, since we only allocated but not freed anything), although clearly
in general this is not a good option.
In the case of `flx', maybe the best option is for it to let-bind
gc-cons-threshold around the code that "allocates without freeing".


        Stefan