[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25606: [DRAFT PATCH 2/2] Signal list cycles in ‘length’ etc.

From: Paul Eggert
Subject: bug#25606: [DRAFT PATCH 2/2] Signal list cycles in ‘length’ etc.
Date: Fri, 3 Feb 2017 12:29:11 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

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.

Attachment: bigmemq.el
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]