From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#73431: Add `setf` support for `stream.el` in ELPA Date: Fri, 04 Oct 2024 08:55:20 +0000 Message-ID: <87zfnk6ydj.fsf@posteo.net> References: <827cc7fc-10be-4b93-bd67-f275193e5d84@protonmail.com> <87tte0q2qc.fsf@posteo.net> <068ecfc3-b452-49a8-89bb-f42012aea5d4@protonmail.com> <6caa1395-a3b2-4e70-b905-1cbfee0f92bd@protonmail.com> <87y138hjij.fsf@web.de> <875xqa8fby.fsf@posteo.net> <932d7782-5685-4a43-b34c-fc0bb3a958e4@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20172"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael_heerdegen@web.de, 73431@debbugs.gnu.org, nicolas@petton.fr, monnier@iro.umontreal.ca To: Okamsn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 04 10:56:25 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1swe6q-00050N-0E for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Oct 2024 10:56:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1swe6U-0003P8-AR; Fri, 04 Oct 2024 04:56:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1swe6R-0003Or-8q for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 04:55:59 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1swe6Q-0000NU-WE for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 04:55:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=3Msiy4d0xTegJYav3IGYkApLfN5j8rlF1FP1WKpTAUI=; b=Kl0AU8ov6yTds7KI/u1tp8fox915gshXHBxi4oX/xfj8w5tGUkisljJ47DjnMiJXrm/3A3sxAMxRD1uckwdn1AGezubrDY1SanRPQ8TYetJ90Ob9w1UaNh2O1H2nGQGIE+MoBwT+ZO1er5hxjYBQg2oSdDRrbTRi0Alr1m/e9Mmi7MOcQuVV6orJHbSy5GMUMwzr/K3IKkP83utY3CZEnGoc/anvT/8iK5zgTs4NnjRF4lqNGzgL01fUsH6fq3nqqGItVKRfivlabito2w533MdR4hgHmbqEnA2riTTqmmPHSNLNV/K+u7hOblG1y528BEWjg7lau9mUtnxjV0qglw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1swe6T-0007vL-SB for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 04:56:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Oct 2024 08:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73431 X-GNU-PR-Package: emacs X-Debbugs-Original-Cc: Michael Heerdegen , "Okamsn via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" , Nicolas Petton , Stefan Monnier , 73431@debbugs.gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.172803213730413 (code B ref -1); Fri, 04 Oct 2024 08:56:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 4 Oct 2024 08:55:37 +0000 Original-Received: from localhost ([127.0.0.1]:34397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swe64-0007uS-ET for submit@debbugs.gnu.org; Fri, 04 Oct 2024 04:55:36 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:56216) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swe62-0007uD-Ds for submit@debbugs.gnu.org; Fri, 04 Oct 2024 04:55:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1swe5z-0003Nh-0B for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 04:55:31 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1swe5w-0000Jt-QS for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 04:55:30 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id DEF4F240028 for ; Fri, 4 Oct 2024 10:55:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1728032123; bh=RoSRH9LAJsk27FnoXlG54AWHkbi7eibjSI6FHGJ9bQg=; h=From:To:Cc:Subject:Autocrypt:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding:From; b=chEyYld5a7VY8O7RZl86qWYHJbj9yzUXiCmUUO+DIm/WxUsDPQHJt98RYngsamntt xXoTaFRrchIcDdCcFVQVTjdGX2+XzSWSHLx/IJLBHUQaxQBsbeWryv8X63u/sHIGT/ 8pBP9wsh0JV+qE5SanlEOvHtWivN2DTehvJOzI1yTLZ0E1MMqh5tpANVg6gP1ea0zH H9JYnx2GD0321rPAr+OuaJyvNng0nssrATY4mEUwFYflwqNU2a1I/ba5XmyJMxEIvT +RZvnyZkIxaD6+WAftJwpHB54HWZpmCVHLHaq0VIultF9t4DOuW2XJ3LijUaU/fN6L pqZ7bAfNvalyA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4XKj6y3FwWz6tw6; Fri, 4 Oct 2024 10:55:22 +0200 (CEST) In-Reply-To: <932d7782-5685-4a43-b34c-fc0bb3a958e4@protonmail.com> (okamsn@protonmail.com's message of "Thu, 03 Oct 2024 00:19:28 +0000") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292953 Archived-At: Okamsn writes: > Philip Kaludercic wrote: >> Okamsn writes: >>> Michael Heerdegen wrote: >>>> Does changing the internal representation of streams have an effect >>>> on the speed of the run code? >>> >>> I think that it does make it slower. I am trying to test it, and I think >>> that making records is slower than making cons cells. I think that >>> accessing the rest of the stream takes longer because the accessors >>> created by `cl-defstruct` always perform type checking. It seems to take >>> about twice as long when compared to naively using `car` and `cdr`. >>> >>> Do you think that it would be better to disable the type checking in the >>> accessors? If so, would you please share how to do that? The manual >>> talks about using `(optimize (safety 0))` in a declare form, but it also >>> seems to say that it cannot be done locally for just the `cl-defstruct` >>> usage. If it cannot be done, do think it makes sense to use >>> `make-record` directly, along with custom function to replace the >>> generated accessors? >>=20 >> It the overhead noticeable, or just measurable? > > I=E2=80=99m not sure what counts as =E2=80=9Cnoticeable=E2=80=9D. I'd say that real-world code that uses stream.el gets slower. For me the main value of synthetic benchmarks is only the speed difference in orders of magnitude and in the number of GC interrupts. > Using the benchmark macros given at=20 > https://github.com/alphapapa/emacs-package-dev-handbook#benchmarking, I=20 > tested getting the "first" and =E2=80=9Crest=E2=80=9D of streams, both as= fresh streams=20 > and as already evaluated streams. > > These are the results I get for a stream from a list using the current=20 > implementation: > > | Form | Tot. runtime | # of GCs | Tot. GC runtime | > |--------------------------+--------------+----------+-----------------| > | stream 10 evald: rest | 0.015259 | 0 | 0 | > | stream 10: rest | 0.044525 | 0 | 0 | > | stream 10 evald: first | 0.059650 | 0 | 0 | > | stream 10: first | 0.074379 | 0 | 0 | > | stream 100: rest | 0.132317 | 0 | 0 | > | stream 100 evald: rest | 0.132821 | 0 | 0 | > | stream 100 evald: first | 0.198041 | 0 | 0 | > | stream 100: first | 0.205684 | 0 | 0 | > | stream 1000 evald: rest | 1.249168 | 0 | 0 | > | stream 1000: rest | 1.250730 | 0 | 0 | > | stream 1000 evald: first | 1.835921 | 0 | 0 | > | stream 1000: first | 1.857300 | 0 | 0 | > > These are the results I get for a stream from a list using the=20 > struct-based implementation: > > | Form | Tot. runtime | # of GCs | Tot. GC runtime | > |--------------------------+--------------+----------+-----------------| > | stream 10 evald: rest | 0.036241 | 0 | 0 | > | stream 10 evald: first | 0.048213 | 0 | 0 | > | stream 10: rest | 0.048221 | 0 | 0 | > | stream 10: first | 0.048285 | 0 | 0 | > | stream 100 evald: rest | 0.312544 | 0 | 0 | > | stream 100: rest | 0.321046 | 0 | 0 | > | stream 100 evald: first | 0.439694 | 0 | 0 | > | stream 100: first | 0.441674 | 0 | 0 | > | stream 1000: rest | 3.032329 | 0 | 0 | > | stream 1000 evald: rest | 3.142683 | 0 | 0 | > | stream 1000: first | 4.113174 | 0 | 0 | > | stream 1000 evald: first | 4.132561 | 0 | 0 | > > You can see that the struct-based run times are about twice as long. I=20 > think this is from the extra work done by the accessors. For example,=20 > the type-checking is run multiple times when accessing the =E2=80=9Cfirst= =E2=80=9D and=20 > =E2=80=9Crest=E2=80=9D slots, because the accessors are also used in `str= eam--force`. Type checking isn't always that bad; Do you see an (easy) way to avoid type checking from running multiple times? --=20 Philip Kaludercic on siskin