GNU bug report logs - #25606
[DRAFT PATCH 2/2] Signal list cycles in ‘length’ etc.

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25606 <at> debbugs.gnu.org
Subject: Re: bug#25606: [DRAFT PATCH 2/2] Signal list cycles in ‘length’ etc.
Date: Fri, 3 Feb 2017 12:29:11 -0800

[Message part 1 (text/plain, inline)]

On 02/02/2017 11:55 PM, Eli Zaretskii wrote:

> the removal is probably justified for 90% of use cases, maybe
> even more

It's 100%, as in practice any use case that has trouble because of the 
code removal will have significantly worse trouble on every GC (which is 
also noninterruptible). memq calls maybe_quit because of circular lists, 
not because of lists of length 1 billion, as huge lists don't work well 
with Emacs anyway (due to GC).

I wrote a little benchmark to try this out (attached), which used the 
new memq. On my workstation at UCLA the results were either:

1. The benchmark was so large that Emacs froze my system while building 
the test-case list, i.e., before any of the newly-affected code was 
executed. This was due to page thrashing. Obviously the draft change is 
irrelevant here.

2. The benchmark was so small that it finished instantly, from the 
user's viewpoint. Obviously not a problem.

3. The benchmark was medium sized (in my case, this was a list with 100 
million entries), so that Emacs was painfully slow but still barely 
usable while the test case was being built or while garbage collection 
was being done. In this case, the new memq was the least of the user's 
problems, as the new memq was 4x faster than a garbage collect so the 
C-g was delayed annoyingly for GC anyway. That is, GC makes Emacs so 
painful to use even with length-100-million lists that people won't use 
Emacs that way and we don't need to worry about treating such lists 
specially.

Of course I can't test all possible use cases. But if there's a 
practical use case where the draft patch will cause a problem, I haven't 
seen it yet.

By the way, I have found many cases where Emacs master will loop forever 
and will ignore C-g. If you like, I can privately send you an Elisp 
expression that, if you evaluate it, you cannot C-g out of. This problem 
is independent of the draft patch, and is far more serious than the 
somewhat-theoretical discussion we're having about memq and friends.

[bigmemq.el (text/plain, attachment)]

Previous Next

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