From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#25606: [DRAFT PATCH 2/2] Signal list cycles in =?UTF-8?Q?=E2=80=98length=E2=80=99?= etc. Date: Fri, 3 Feb 2017 12:29:11 -0800 Organization: UCLA Computer Science Department Message-ID: <08b0e359-3a9b-49f2-1299-51e899f86712@cs.ucla.edu> References: <20170201235622.30836-1-eggert@cs.ucla.edu> <20170201235622.30836-2-eggert@cs.ucla.edu> <83wpd8v6x8.fsf@gnu.org> <0a01d2ce-ef3e-7db0-6854-1b5e46d49be4@cs.ucla.edu> <83efzfvhbm.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------18EE4DC2DA9AA5EE14CFA383" X-Trace: blaine.gmane.org 1486153816 7834 195.159.176.226 (3 Feb 2017 20:30:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 3 Feb 2017 20:30:16 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 Cc: 25606@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 03 21:30:11 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZkUi-0001ic-Re for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Feb 2017 21:30:09 +0100 Original-Received: from localhost ([::1]:36725 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZkUo-0001Dg-3j for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Feb 2017 15:30:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZkUf-0001BN-Un for bug-gnu-emacs@gnu.org; Fri, 03 Feb 2017 15:30:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZkUc-0005wW-Qm for bug-gnu-emacs@gnu.org; Fri, 03 Feb 2017 15:30:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57183) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cZkUc-0005wQ-Nm for bug-gnu-emacs@gnu.org; Fri, 03 Feb 2017 15:30:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cZkUc-0001jO-8e for bug-gnu-emacs@gnu.org; Fri, 03 Feb 2017 15:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Feb 2017 20:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25606 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 25606-submit@debbugs.gnu.org id=B25606.14861537646585 (code B ref 25606); Fri, 03 Feb 2017 20:30:02 +0000 Original-Received: (at 25606) by debbugs.gnu.org; 3 Feb 2017 20:29:24 +0000 Original-Received: from localhost ([127.0.0.1]:55382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZkU0-0001i9-4Q for submit@debbugs.gnu.org; Fri, 03 Feb 2017 15:29:24 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:44586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZkTx-0001hq-So for 25606@debbugs.gnu.org; Fri, 03 Feb 2017 15:29:22 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id C5E2616006A; Fri, 3 Feb 2017 12:29:15 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id x7U8ERzjlGY9; Fri, 3 Feb 2017 12:29:15 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EF26D16008B; Fri, 3 Feb 2017 12:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OBsqZu_IcDEG; Fri, 3 Feb 2017 12:29:14 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D2D5616006A; Fri, 3 Feb 2017 12:29:14 -0800 (PST) In-Reply-To: <83efzfvhbm.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:128927 Archived-At: This is a multi-part message in MIME format. --------------18EE4DC2DA9AA5EE14CFA383 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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. --------------18EE4DC2DA9AA5EE14CFA383 Content-Type: text/plain; charset=UTF-8; name="bigmemq.el" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bigmemq.el" KGRlZnVuIGJpZ21lbXEgKG4pCiAgKGxldCAoKHQwIChmbG9hdC10aW1lIChjdXJyZW50LXRp bWUpKSkpCiAgICAobWVzc2FnZSAiUnVubmluZyBtYWtlLWxpc3QuLi4iKQogICAgKGxldCAo KGxvbmcgKG1ha2UtbGlzdCBuIG5pbCkpCiAgICAgICAgICAodDEgKGZsb2F0LXRpbWUgKGN1 cnJlbnQtdGltZSkpKSkKICAgICAgKG1lc3NhZ2UgIlJ1bm5pbmcgbWFrZS1saXN0Li4uIGRv bmUgaW4gJXMgc2Vjb25kcyIgKC0gdDEgdDApKQogICAgICAobWVzc2FnZSAiUnVubmluZyBt ZW1xLi4uIikKICAgICAgKGxldCAoKHJlc3VsdCAobWVtcSB0IGxvbmcpKQogICAgICAgICAg ICAodDIgKGZsb2F0LXRpbWUgKGN1cnJlbnQtdGltZSkpKSkKICAgICAgICAobWVzc2FnZSAi UnVubmluZyBtZW1xLi4uIGRvbmUgaW4gJXMgc2Vjb25kcyIgKC0gdDIgdDEpKQogICAgICAg IChtZXNzYWdlICJSdW5uaW5nIGdhcmJhZ2UtY29sbGVjdC4uLiIpCiAgICAgICAgKGdhcmJh Z2UtY29sbGVjdCkKICAgICAgICAobGV0ICgodDMgKGZsb2F0LXRpbWUgKGN1cnJlbnQtdGlt ZSkpKSkKICAgICAgICAgIChtZXNzYWdlICJSdW5uaW5nIGdhcmJhZ2UtY29sbGVjdC4uLiBk b25lIGluICVzIHNlY29uZHMiICgtIHQzIHQyKSkpCiAgICAgICAgcmVzdWx0KSkpKQo= --------------18EE4DC2DA9AA5EE14CFA383--