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))))
next prev parent 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.