From: Adam Porter <adam@alphapapa.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: luangruo@yahoo.com, emacs-devel@gnu.org, sbaugh@catern.com,
stefankangas@gmail.com
Subject: Re: Turning on savehist-mode by default
Date: Sun, 17 Dec 2023 05:19:31 -0600 [thread overview]
Message-ID: <f020ae64-c253-4758-bc19-d6f1bd2a78cf@alphapapa.net> (raw)
In-Reply-To: <831qbll01p.fsf@gnu.org>
On 12/17/23 02:12, Eli Zaretskii wrote:
>> Date: Sat, 16 Dec 2023 23:42:15 -0600
>> Cc: eliz@gnu.org, emacs-devel@gnu.org, sbaugh@catern.com,
>> stefankangas@gmail.com
>> From: Adam Porter <adam@alphapapa.net>
>>
>> In addition to what Po said, I'd like to gently reiterate what I said
>> earlier in this thread: Given my experience with savehist causing
>> unexpected and hard-to-debug performance problems[0]
>
> That mentions a single 3rd-party package that triggers the issue, and
> includes a workaround solution. I see nothing awful there.
From my perspective, as the developer of the package being accused of
having performance problems by random users, problems I couldn't
reproduce, nor even begin to guess what the cause was, or if it was even
an actual problem, it felt pretty awful.
>> I'd guess that there are more such cases in the wild waiting to be
>> triggered.
>
> You know about other packages that add huge elements to history
> variables? Which ones?
My package does not add huge elements to history variables. It simply
passes arguments to functions via their interactive forms. I didn't
even know that such history variables existed until that bug report came
to its conclusion, and I've used Emacs for years and published tens of
packages which together have nearly a million downloads. So if it can
happen to me, it can probably happen to anyone.
>> If, e.g. Emacs 30.1 enabled it by default, I can imagine a number
>> of users suddenly encountering weird pauses, and they'd probably
>> blame GC initially[1].
>
> This remains to be seen, and having this on master enough time in
> advance will allow such reports to come in, if indeed such problems
> exist.
You may be right, considering how many users who build master have been
speaking up lately. Still, my concern is that whether the problem
happens depends very much on a user's established workflows and
installed packages. Some users will never encounter the problem, and
other users will encounter it constantly, and those who do won't have a
clue what's going on, because it's heavily obscured. I don't know what
sample size would be needed to be likely to detect such problems, but it
wouldn't be small, given that probably 0.1% or less of the users of
Ement.el seemed to experience the problem--but for those who did, it was
crippling to their Emacs usage.
> We could also introduce a limitation of element size (a defcustom) to
> be imposed by add-to-history, if we think such long elements are
> detrimental to performance.
That would likely be necessary, yes. No one wants 450 MB savehist files
in their .emacs.d getting rewritten every few minutes.
>> As well, I have some concerns about savehist's having the potential to
>> cause weird bugs in other libraries: The savehist-save function seems to
>> comment out individual elements of savehist-minibuffer-history-variables
>> that it determines are unreadable. That's understandable from its
>> perspective, but what effect will that have on libraries that may not be
>> expecting for their data structures to have certain parts disappear
>> after restarting Emacs? I can just imagine the bug reports from users
>> showing apparently corrupted or elided data structures, and having no
>> clue as to what is mutating them, because the code isn't within the
>> library having a bug reported against it.
>
> If such bug reports will come in, we will handle them. As we do with
> any other Emacs feature. Why worry in advance, when we don't yet have
> any such reports, and therefore can do nothing about them?
I guess it's a matter of perspective--from mine, I'm sharing such a report.
next prev parent reply other threads:[~2023-12-17 11:19 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-18 14:54 Turning on savehist-mode by default sbaugh
2023-11-18 16:33 ` [External] : " Drew Adams
2023-11-18 18:19 ` Philip Kaludercic
2023-11-18 21:06 ` Drew Adams
2023-11-18 21:42 ` Philip Kaludercic
2023-11-18 23:01 ` Drew Adams
2023-11-19 6:02 ` Eli Zaretskii
2023-11-19 6:56 ` Drew Adams
2023-11-19 7:05 ` Juri Linkov
2023-11-19 7:32 ` Yuri Khan
2023-11-19 8:26 ` Eli Zaretskii
2023-11-19 9:06 ` Yuri Khan
2023-11-19 9:24 ` Eli Zaretskii
2023-11-19 15:09 ` Spencer Baugh
2023-11-20 9:53 ` Manuel Giraud via Emacs development discussions.
2023-11-20 12:23 ` Eli Zaretskii
2023-11-20 13:15 ` Manuel Giraud via Emacs development discussions.
2023-11-20 14:05 ` Eli Zaretskii
2023-11-23 15:57 ` Eli Zaretskii
2023-11-23 16:31 ` Manuel Giraud via Emacs development discussions.
2023-11-20 16:57 ` Drew Adams
2023-11-20 18:34 ` Eli Zaretskii
2023-11-20 18:54 ` Drew Adams
2023-11-20 19:16 ` Eli Zaretskii
2023-11-19 16:42 ` Drew Adams
2023-11-19 16:42 ` Drew Adams
2023-11-19 16:27 ` Visuwesh
2023-11-19 17:33 ` sbaugh
2023-11-19 6:59 ` Po Lu
2023-11-19 7:10 ` Eli Zaretskii
2023-11-19 7:27 ` Po Lu
2023-11-19 8:23 ` Eli Zaretskii
2023-11-19 14:08 ` Dmitry Gutov
2023-11-19 14:38 ` Po Lu
2023-11-19 14:43 ` Dmitry Gutov
2023-11-20 0:11 ` Po Lu
2023-11-19 15:17 ` Spencer Baugh
2023-11-20 0:09 ` Po Lu
2023-11-20 3:15 ` sbaugh
2023-11-20 3:40 ` Po Lu
2023-11-20 14:32 ` Spencer Baugh
2023-11-20 5:55 ` [OT] Not clobbering bash history brickviking
2023-11-20 17:50 ` Juri Linkov
2023-11-22 3:01 ` [OT] " Richard Stallman
2023-11-22 3:32 ` Arsen Arsenović
2023-11-25 2:58 ` Richard Stallman
2023-11-26 10:20 ` Arsen Arsenović
2023-12-04 3:10 ` Richard Stallman
2023-12-04 13:05 ` Arsen Arsenović
2023-12-08 3:54 ` Richard Stallman
2023-12-16 18:56 ` Turning on savehist-mode by default Stefan Kangas
2023-11-20 3:08 ` Richard Stallman
2023-11-20 3:16 ` Spencer Baugh
2023-11-28 11:04 ` Thanos Apollo
2023-11-28 14:11 ` Thanos Apollo
2023-11-28 14:38 ` Eli Zaretskii
2023-11-28 21:07 ` Adam Porter
2023-11-28 21:46 ` Dmitry Gutov
2023-11-29 12:31 ` Eli Zaretskii
2023-12-01 1:50 ` Björn Bidar
2023-12-16 19:01 ` Stefan Kangas
2023-12-16 19:40 ` Eli Zaretskii
2023-12-16 22:57 ` Stefan Kangas
2023-12-16 23:57 ` Po Lu
2023-12-17 5:42 ` Adam Porter
2023-12-17 7:49 ` Stefan Kangas
2023-12-17 11:09 ` Adam Porter
2023-12-22 10:45 ` Stefan Kangas
2023-12-22 11:48 ` Visuwesh
2023-12-22 11:52 ` Adam Porter
2023-12-22 14:22 ` Yuri Khan
2023-12-17 12:02 ` Adam Porter
2023-12-17 8:12 ` Eli Zaretskii
2023-12-17 11:19 ` Adam Porter [this message]
2023-12-17 12:11 ` Eli Zaretskii
2023-12-19 3:49 ` Richard Stallman
2023-12-17 18:48 ` [External] : " Drew Adams
2023-12-17 7:50 ` Eli Zaretskii
2023-12-17 11:48 ` Po Lu
2023-12-17 12:26 ` Eli Zaretskii
2023-12-17 13:31 ` Po Lu
2023-12-17 13:45 ` Eli Zaretskii
2023-12-17 17:55 ` Juergen Fenn
2023-12-17 18:09 ` Eli Zaretskii
2023-12-17 19:51 ` Juergen Fenn
2023-12-17 20:20 ` Eli Zaretskii
2023-12-17 20:21 ` Dmitry Gutov
2023-12-17 20:38 ` Juergen Fenn
2023-12-17 20:52 ` Dmitry Gutov
2023-12-17 21:12 ` [External] : " Drew Adams
2023-12-17 21:16 ` Dmitry Gutov
2023-12-17 21:47 ` Juergen Fenn
2023-12-17 22:22 ` Drew Adams
2023-12-17 21:55 ` Drew Adams
2023-12-17 21:57 ` Dmitry Gutov
2023-12-17 22:34 ` Drew Adams
2023-12-18 0:47 ` Po Lu
2023-12-18 3:36 ` Eli Zaretskii
2023-12-17 7:40 ` Eli Zaretskii
2023-12-17 10:03 ` tomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f020ae64-c253-4758-bc19-d6f1bd2a78cf@alphapapa.net \
--to=adam@alphapapa.net \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=luangruo@yahoo.com \
--cc=sbaugh@catern.com \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).