all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 25606@debbugs.gnu.org
Subject: bug#25606: [DRAFT PATCH 2/2] Signal list cycles in ‘length’ etc.
Date: Fri, 3 Feb 2017 12:29:11 -0800	[thread overview]
Message-ID: <08b0e359-3a9b-49f2-1299-51e899f86712@cs.ucla.edu> (raw)
In-Reply-To: <83efzfvhbm.fsf@gnu.org>

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

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 #2: bigmemq.el --]
[-- Type: text/plain, Size: 644 bytes --]

(defun bigmemq (n)
  (let ((t0 (float-time (current-time))))
    (message "Running make-list...")
    (let ((long (make-list n nil))
          (t1 (float-time (current-time))))
      (message "Running make-list... done in %s seconds" (- t1 t0))
      (message "Running memq...")
      (let ((result (memq t long))
            (t2 (float-time (current-time))))
        (message "Running memq... done in %s seconds" (- t2 t1))
        (message "Running garbage-collect...")
        (garbage-collect)
        (let ((t3 (float-time (current-time))))
          (message "Running garbage-collect... done in %s seconds" (- t3 t2)))
        result))))

  reply	other threads:[~2017-02-03 20:29 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-01 23:56 bug#25605: [DRAFT PATCH 1/2] Simplify use of FOR_EACH_TAIL Paul Eggert
2017-02-01 23:56 ` bug#25606: [DRAFT PATCH 2/2] Signal list cycles in ‘length’ etc Paul Eggert
2017-02-02 17:28   ` Eli Zaretskii
2017-02-02 23:01     ` Paul Eggert
2017-02-03  7:55       ` Eli Zaretskii
2017-02-03 20:29         ` Paul Eggert [this message]
2017-02-04  9:05           ` Eli Zaretskii
2017-02-04 19:11             ` Paul Eggert
2017-02-04 19:52               ` Eli Zaretskii
2017-02-04 21:45                 ` Paul Eggert
2017-02-05 18:45                   ` Eli Zaretskii
2017-02-05 21:17                     ` Paul Eggert
2017-02-02 17:29 ` bug#25605: [DRAFT PATCH 1/2] Simplify use of FOR_EACH_TAIL Eli Zaretskii
2017-02-05 21:30 ` bug#25605: patches installed for 25605, 25606 Paul Eggert
2017-02-06 16:04   ` bug#25605: bug#25606: " Eli Zaretskii
2017-02-07  6:53     ` Paul Eggert
2017-02-07 12:47       ` Philipp Stephani
2017-02-07 16:32         ` bug#25605: " Paul Eggert
2017-02-07 21:47           ` Philipp Stephani
2017-02-07 22:20             ` Paul Eggert
2017-02-07 22:55               ` Philipp Stephani
2017-02-10  9:59       ` bug#25605: " Eli Zaretskii
2017-02-12  8:31         ` Paul Eggert
2017-02-12 16:13           ` bug#25605: " Eli Zaretskii
2017-02-12 18:55             ` Paul Eggert
2017-02-12 19:33               ` Eli Zaretskii
2017-02-12 19:41                 ` bug#25605: " Lars Ingebrigtsen
2017-02-12 19:49                   ` bug#25606: " Lars Ingebrigtsen
2017-02-12 20:22                   ` Eli Zaretskii
2017-02-12 19:43                 ` Paul Eggert
2017-02-13  9:11                 ` Michael Albinus
2017-02-13 14:37                   ` Eli Zaretskii
2017-02-12 19:41               ` Eli Zaretskii
2017-02-12 20:57                 ` bug#25605: " Paul Eggert
2017-02-13  5:37                   ` Eli Zaretskii

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=08b0e359-3a9b-49f2-1299-51e899f86712@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=25606@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.