GNU bug report logs - #14518
abbrev edits - delay when saving

Previous Next

Package: emacs;

Reported by: Andreas Röhler <andreas.roehler <at> easy-emacs.de>

Date: Fri, 31 May 2013 09:30:02 UTC

Severity: minor

Tags: moreinfo, unreproducible, wontfix

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #67 received at 14518 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
Cc: 14518 <at> debbugs.gnu.org
Subject: Re: bug#14518: C and Emacs Lisp code parts
Date: Wed, 06 Jul 2016 20:35:38 +0300
> Cc: 14518 <at> debbugs.gnu.org
> From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
> Date: Wed, 6 Jul 2016 19:27:24 +0200
> 
> .abbrev_defs here counts 18415 lines. Can't post it as such, as it may 
> contain private data.

OK, but then please collect the additional data I asked for, and post
that.  It might give us some clues.

> AFAIU the slowness is result of a proceeding, which reads/writes all 
> available abbrev tables.

It is too slow.  37 sec to write 18K strings is unbelievably slow with
today's machines.  Glenn presented a similar scenario with a very
similar number of abbrevs, which is 2 orders of magnitude faster.  So
there's something at work here that we need to understand, because my
gut feeling is that it is not directly related to abbrevs.el or Lisp
vs C in general.

> A solution would restrict that read/write to mode-abbrev table at stake, 
> or better to single abbrev edited.
> Maybe edit-abbrev should be changed into edit-all-abbrev-at-once - but 
> discouraged.

IME, it is not a good idea to discuss solutions before the problem is
sufficiently understood.  We are not there yet.  Let's analyze this
some more.

Thanks.




This bug report was last modified 8 years and 218 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.