From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 12:11:14 2022 Received: (at submit) by debbugs.gnu.org; 9 Aug 2022 16:11:14 +0000 Received: from localhost ([127.0.0.1]:44586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLRp3-0007Oq-Oo for submit@debbugs.gnu.org; Tue, 09 Aug 2022 12:11:13 -0400 Received: from lists.gnu.org ([209.51.188.17]:46712) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLRp1-0007Oi-0m for submit@debbugs.gnu.org; Tue, 09 Aug 2022 12:11:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35950) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLRp0-00033v-Rh for bug-gnu-emacs@gnu.org; Tue, 09 Aug 2022 12:11:10 -0400 Received: from mail-vs1-f49.google.com ([209.85.217.49]:37437) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oLRoz-00011g-AM for bug-gnu-emacs@gnu.org; Tue, 09 Aug 2022 12:11:10 -0400 Received: by mail-vs1-f49.google.com with SMTP id 66so12389710vse.4 for ; Tue, 09 Aug 2022 09:11:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=kQSP3WorPzo2qX6aFSsiMumKvlHoGhnxuJAo/NOP2ao=; b=L5Tp6OJlNP/M9IoSLHSPUjNG4hkvWCQN8eMyD2x4uY2RRZXeyciV4Wd6WI3khBIU3I SiyP//0Gb6xA0mj8hfZOrmR+EzlSOu0AbCWlpabjy13vheCN7/TqaPn4YlflhVCkKh7V W6wY8MANVv8r/OlfsYWwfGo+Aw/8umUGplet38frAJxdKcLUrlnjY4YvUlJeTM7k5Ul/ AMLR5i531j350d+jFxivmMxo5GOXSi3sY0e0xFs9HFqy6HqFLmIkZiWVC7voXHA320OF brpEnudK1X+FGKKjXcyqWASNWeoyuQ7YmJSVcg1AN3vIUJ1KF+R1Br2c3ZAR56+MaS9o nhIg== X-Gm-Message-State: ACgBeo28Q7CHLzoaB+RXza/qroHpeTQARLTMzk+CDUJZzNk0YJ46pihR bAdbaMrUeLlOCo4Swq2gwj7vfg1n/hbfTX6ZkzOM3jkd X-Google-Smtp-Source: AA6agR5MiDk8veBFouP28tnEOTW+sWP66XXF8PfDajbH8uY5iYWUTk93vqeUyZdTfXRy9VPgWp2NexzPDbBLdNakvrk= X-Received: by 2002:a05:6102:7c6:b0:37d:34bd:8564 with SMTP id y6-20020a05610207c600b0037d34bd8564mr9685712vsg.59.1660061467854; Tue, 09 Aug 2022 09:11:07 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 9 Aug 2022 09:11:07 -0700 From: Stefan Kangas MIME-Version: 1.0 Date: Tue, 9 Aug 2022 09:11:07 -0700 Message-ID: Subject: 29.0.50; Performance of seq-uniq is not very good To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=209.85.217.49; envelope-from=stefankangas@gmail.com; helo=mail-vs1-f49.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) Severity: minor `seq-uniq' is not very performant compared to `-uniq' (from dash.el) and even slower compared to the recently removed `gnus-delete-duplicates': (benchmark-run 10000 (seq-uniq '(a c b c c a d))) => (0.355001481 1 0.2518970439999748) (benchmark-run 10000 (-uniq '(a c b c c a d))) => (0.006599549 0 0.0) (benchmark-run 10000 (gnus-delete-duplicates '(a c b c c a d))) => (0.0034537929999999997 0 0.0) Could we improve the performance of `seq-uniq' for lists? PS. `gnus-delete-duplicates' was recently removed but looks like this: (defun gnus-delete-duplicates (list) "Remove duplicate entries from LIST." (let ((result nil)) (while list (unless (member (car list) result) (push (car list) result)) (pop list)) (nreverse result))) From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 12:47:50 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 16:47:50 +0000 Received: from localhost ([127.0.0.1]:44644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLSOT-00022X-Vj for submit@debbugs.gnu.org; Tue, 09 Aug 2022 12:47:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58444) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLSOS-00021o-B3 for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 12:47:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:42912) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLSON-0007M0-32; Tue, 09 Aug 2022 12:47:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=6aJd25w3vq0hoarY6hczHUTEscKpuKuhMSs8VfqOBw0=; b=cwyp+OM4IIje VQZDz01MjTytEJwwV1oBE6yNsYcpS/YQr/FbLStn8yM7JBQkU3/HiYlyLQ+YIBOZQYTD20VlZjCpj EvuQocyW0mheRuUUyGrQQBN1h+r0bNsPNs0fe+uR5gJMyQOgdGPkmnzHjOZ+V1foHEN1dUA4/M+3z 9T1e+ATVTRNOzAQAPJTikLGE3B86CxvjjseknBxMI8crUa3qAQ9ugQ5v0/PBvgak2z986eWNp63wt g1AMYuC8FjrSqTSv1KDQioGgpLt+xWW7/E4sPvNG/YbE83WmnwtXgutaBbb3havuRcvnf3lGLz/OY 23f86EQbc5KAeR2Xgv3LPw==; Received: from [87.69.77.57] (port=2173 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLSOM-0002rM-EA; Tue, 09 Aug 2022 12:47:42 -0400 Date: Tue, 09 Aug 2022 19:47:33 +0300 Message-Id: <83tu6ltlcq.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Tue, 9 Aug 2022 09:11:07 -0700) Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Tue, 9 Aug 2022 09:11:07 -0700 > > Severity: minor > > `seq-uniq' is not very performant compared to `-uniq' (from dash.el) and > even slower compared to the recently removed `gnus-delete-duplicates': > > (benchmark-run 10000 (seq-uniq '(a c b c c a d))) > => (0.355001481 1 0.2518970439999748) > > (benchmark-run 10000 (-uniq '(a c b c c a d))) > => (0.006599549 0 0.0) > > (benchmark-run 10000 (gnus-delete-duplicates '(a c b c c a d))) > => (0.0034537929999999997 0 0.0) > > Could we improve the performance of `seq-uniq' for lists? What's wrong with using delete-dups for your cases above? From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 12:57:46 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 16:57:46 +0000 Received: from localhost ([127.0.0.1]:44663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLSY6-0002Jl-BN for submit@debbugs.gnu.org; Tue, 09 Aug 2022 12:57:46 -0400 Received: from quimby.gnus.org ([95.216.78.240]:51708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLSY4-0002JX-B3 for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 12:57:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=v4Ln5Jth+e3Gt9ouDI2XvuBw9YTNh87ePHyvD5CBLJs=; b=hLyAq72rR4HCTDwhnKuwCkBf6A XY0uwicPnOeqm2P8DC5w4pAkBYuKKr62Ppk6taASHa+lrXwdq9WjLeQTGmLqFIryZhbIFl6gkFyP+ AXRBOxeu+6tKXntNsc/QX4G1HYH7C4A+JOgTYnG6HXEB7QALgw9vdogSVHWN0AkqJryM=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oLSXu-0005Fp-L9; Tue, 09 Aug 2022 18:57:36 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <83tu6ltlcq.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 09 Aug 2022 19:47:33 +0300") References: <83tu6ltlcq.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEVKM0NrTmCaYG+n d4bKo6bq1NL9/Pn///+7/GaRAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+YICRA4NRy7jdwAAAGpSURB VDjLrZNR1pwgDIXDrIDo6QKA9r1jaJ/bMaxgxBVU97+E3qDO/5/qvPUej0fycQPEQNTkuihZTVOp 0KTEpj5jsO5a1gUjgF6kvKK7AHqBv16B3NKu/xJKivC8noEte5qPHRg4z4dIS72KL6SXcXNcZ1qp vHPUd4763vHfQC5vAGe9NFGe9JIglZX3fBj8KJx9ORPipBY9A9ej8OeqLHAgV/lMlhmpnwa0akE3 HZr0x5OZuDNLXetBljH0d9+aszVKa4mlzvW3tSa61rORMQ9Z5ymXSbxrcSgFTg9hzvXJ/d3mbn3u 0hAh776Od77pSIdclMC93jk+PH1Z/7wAcwpORyYXiH6WX0S36JEt4saEbmD27vadviXHUjSERHaR bK/2nmzfZVKR6ElkA3V724xRYuTm2K+dlnYLxyEGHEW2GzXXp+6CIbB/rVHHIyxD4N3RUqEmikdE WiaA3HKNg6BiYgod2zlSW0VHlNKiQ+w8W72Yu+ZBAEFs1BbeKsIBpDyCgZhexH5LwiISO9TYCn1Y DMWoGO/giDd2u3cNWBz6QK59Oj7k6C/EWzVZFfI3TwAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0w OC0wOVQxNjo1Njo1MyswMDowMM69Sn4AAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDgtMDlUMTY6 NTY6NTMrMDA6MDC/4PLCAAAAAElFTkSuQmCC X-Now-Playing: Hood's _Cold House_: "You Show No Emotion At All" Date: Tue, 09 Aug 2022 18:57:33 +0200 Message-ID: <87y1vxwe0y.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > What's wrong with using delete-dups for your cases above? delete-dups is destructive. You can copy the list first, of course, but seq-uniq should be much faster than it is. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > What's wrong with using delete-dups for your cases above? delete-dups is destructive. You can copy the list first, of course, but seq-uniq should be much faster than it is. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 13:07:38 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 17:07:38 +0000 Received: from localhost ([127.0.0.1]:44690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLShe-0002b5-Dj for submit@debbugs.gnu.org; Tue, 09 Aug 2022 13:07:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLShY-0002ao-UV for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 13:07:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43266) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLShT-0002Dz-Ec; Tue, 09 Aug 2022 13:07:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+dSLycMwbAbzFgeBUt72V8kUvSccPqiNIK1/dgQEiFk=; b=V4q8bnOTnt50 OmqNDtG1Py9pnReBCs0dTgoPJdrntKHtRo6noRmSvViaXfL1WtCimVPJtwYVwSdg84qS8F71PJke+ FQJqeKs/4rCCmJKgG2runzz5Ykwcdi7oB7ScobIXrUPPZQFzZg2Z/J0tAYl2tQsQtNYZ3mByG+0uW Y8ixf9VFvUX9TkeU3uaifsxlVrGCTgnLw7519XGZ3fxLEW9vT+tXb+THsyyRvuEED3/5kJEDAuact m/+QiLPHdRZaBAP3E96djZCTV0yJrIwJiPvvjDwtkp3CGWyZFMTAJM8GG83QjTffQ1YiNsjaRJTGa OOPlq/yp40wBaOudoYSf0w==; Received: from [87.69.77.57] (port=3392 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLShS-0000Xu-SO; Tue, 09 Aug 2022 13:07:27 -0400 Date: Tue, 09 Aug 2022 20:07:17 +0300 Message-Id: <83lerxtkfu.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87y1vxwe0y.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 09 Aug 2022 18:57:33 +0200) Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Stefan Kangas , 57079@debbugs.gnu.org > Date: Tue, 09 Aug 2022 18:57:33 +0200 > > Eli Zaretskii writes: > > > What's wrong with using delete-dups for your cases above? > > delete-dups is destructive. No one said that was a problem in these cases. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 13:18:39 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 17:18:39 +0000 Received: from localhost ([127.0.0.1]:44778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLSsJ-0002x6-49 for submit@debbugs.gnu.org; Tue, 09 Aug 2022 13:18:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLSsH-0002wt-Bx for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 13:18:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43776) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLSsB-0004Bk-RQ; Tue, 09 Aug 2022 13:18:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=DWOJx7272S53PV6/s3ssHbAeDgytxbOsJy+rS5c7tqE=; b=pXB0tIFHDUdd wdCOSy09HShvDFnNAAdKdpxj69EiK0hbMuMU4ef3si/WehxNodOe+GE3WfQ7siAyxNVxTTimNtxIn vmt/qt1hjBO2A5xmOuSwTZAAb64MEQ7+fkNpBGt5Ukm1CXERD7vnkgSgsD+IAOeh5YzlHjMTnKjyl 7qQHOTX5UKXEC3kY7IJEeSCWic0+krWNwNeAM6Dyqq3TsZ7IvQ+0zsx5CIME9k8iUp+lBzgIKmUEQ cxyU+HDmZZzsNjXF/tQjaQhfhfaiy/KwDEGipFWdRsJC/zSAOorveRce1SxxLf0aZw+7c6/KJUs5G 1JUjUY5KzyAt8SHAT3d9HA==; Received: from [87.69.77.57] (port=4098 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLSsB-00029V-BG; Tue, 09 Aug 2022 13:18:31 -0400 Date: Tue, 09 Aug 2022 20:18:20 +0300 Message-Id: <83k07htjxf.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87y1vxwe0y.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 09 Aug 2022 18:57:33 +0200) Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Stefan Kangas , 57079@debbugs.gnu.org > Date: Tue, 09 Aug 2022 18:57:33 +0200 > > Eli Zaretskii writes: > > > What's wrong with using delete-dups for your cases above? > > delete-dups is destructive. You can copy the list first, of course, but > seq-uniq should be much faster than it is. How much faster? Using copy-sequence and delete-dups is 7 times faster here than seq-uniq and twice faster than gnus-delete-duplicates. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 13:21:37 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 17:21:37 +0000 Received: from localhost ([127.0.0.1]:44782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLSvA-00031z-NW for submit@debbugs.gnu.org; Tue, 09 Aug 2022 13:21:36 -0400 Received: from quimby.gnus.org ([95.216.78.240]:51878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLSv8-00031k-0L for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 13:21:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=T59o3o+gdc+pXUWLhsSpL9dnghmX/SL9ReiXIQ62T5c=; b=l7c236EFTn0o+8v7zjOPDCmo2z UhsLe9s9xOjBYSMX5gAj79V7vwQ4LDqnOy1XFHT9kR/32kVCeCdHBwMGCj9KYvFvYZW7ls34EVcI2 tMYprNgdBfJHjQbWpU91nwfCPpOeRrGY8gqfuLfMFx0WjyuQ6v1777VOlgud8A03mhEs=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oLSuz-0005tQ-9r; Tue, 09 Aug 2022 19:21:27 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <83lerxtkfu.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 09 Aug 2022 20:07:17 +0300") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83lerxtkfu.fsf@gnu.org> X-Now-Playing: Hood's _Cold House_: "The River Curls Around The Town" Date: Tue, 09 Aug 2022 19:21:24 +0200 Message-ID: <87tu6lwcx7.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > No one said that was a problem in these cases. I haven't audited the callers, but changing code that used to be non-destructive to be destructive isn't to be taken lightly. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > No one said that was a problem in these cases. I haven't audited the callers, but changing code that used to be non-destructive to be destructive isn't to be taken lightly. Anyway, I've now made seq-uniq faster. This used to take 27 seconds, and now takes 1.4s. (let ((list (seq-map-indexed (lambda (_ i) i) (make-list 10000 nil)))) (setq list (append list list)) ;;(benchmark-run 10 (gnus-delete-duplicates list)) (benchmark-run 10 (seq-uniq list)) ) From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 13:21:44 2022 Received: (at control) by debbugs.gnu.org; 9 Aug 2022 17:21:44 +0000 Received: from localhost ([127.0.0.1]:44785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLSvI-00032J-0L for submit@debbugs.gnu.org; Tue, 09 Aug 2022 13:21:44 -0400 Received: from quimby.gnus.org ([95.216.78.240]:51892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLSvF-00031x-NR for control@debbugs.gnu.org; Tue, 09 Aug 2022 13:21:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=5RMl+Cr4t8WSx2+0zu/DX8HmyDuCZc+9uxrRYCwk52c=; b=ZkEVSHeEW7hYVFkj8dPsans9qf 8LRVT1AVQaJYYsgu4EFnZFo4NMU87o/PjLzD65yqBe7G0WzsYDTrZTY2F4RdNzVyYtiy82xxNsk6k CG86CZoouieYTw+UcvCK4kmdAnzg4ulnVC39mnKSbqwhCdnWK7Xh0YSo5+Sp7X+kwjug=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oLSv7-0005tn-SK for control@debbugs.gnu.org; Tue, 09 Aug 2022 19:21:35 +0200 Date: Tue, 09 Aug 2022 19:21:33 +0200 Message-Id: <87sfm5wcwy.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #57079 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 57079 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 57079 29.1 quit From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 13:23:21 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 17:23:21 +0000 Received: from localhost ([127.0.0.1]:44800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLSwr-000362-5e for submit@debbugs.gnu.org; Tue, 09 Aug 2022 13:23:21 -0400 Received: from quimby.gnus.org ([95.216.78.240]:51940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLSwp-00035q-OA for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 13:23:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zWAX/69G2yF6WPQnD7IXC6qn9jHbL9Ca+SSNw855isM=; b=W8Ov40c5WrNTAbPTwV2i+P+qFe HTm8NZes6FsTZhCBj9ZyX7YeTJqzOwf/cafjo7fJildkt4rHNtpsomVSTnPCt5pqXfKYMgVaR1j2R YjPjfZTQG8sNvkjBWt7tLPYtdKJodL/XkEOj9uHzRFBYQUKFpNgjeCZowbTB/KsAFn18=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oLSwh-0005wa-Ps; Tue, 09 Aug 2022 19:23:13 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <83k07htjxf.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 09 Aug 2022 20:18:20 +0300") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEVKM0NrTmCaYG+n d4bKo6bq1NL9/Pn///+7/GaRAAAAAWJLR0QHFmGI6wAAAAd0SU1FB+YICRA4NRy7jdwAAAGpSURB VDjLrZNR1pwgDIXDrIDo6QKA9r1jaJ/bMaxgxBVU97+E3qDO/5/qvPUej0fycQPEQNTkuihZTVOp 0KTEpj5jsO5a1gUjgF6kvKK7AHqBv16B3NKu/xJKivC8noEte5qPHRg4z4dIS72KL6SXcXNcZ1qp vHPUd4763vHfQC5vAGe9NFGe9JIglZX3fBj8KJx9ORPipBY9A9ej8OeqLHAgV/lMlhmpnwa0akE3 HZr0x5OZuDNLXetBljH0d9+aszVKa4mlzvW3tSa61rORMQ9Z5ymXSbxrcSgFTg9hzvXJ/d3mbn3u 0hAh776Od77pSIdclMC93jk+PH1Z/7wAcwpORyYXiH6WX0S36JEt4saEbmD27vadviXHUjSERHaR bK/2nmzfZVKR6ElkA3V724xRYuTm2K+dlnYLxyEGHEW2GzXXp+6CIbB/rVHHIyxD4N3RUqEmikdE WiaA3HKNg6BiYgod2zlSW0VHlNKiQ+w8W72Yu+ZBAEFs1BbeKsIBpDyCgZhexH5LwiISO9TYCn1Y DMWoGO/giDd2u3cNWBz6QK59Oj7k6C/EWzVZFfI3TwAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0w OC0wOVQxNjo1Njo1MyswMDowMM69Sn4AAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDgtMDlUMTY6 NTY6NTMrMDA6MDC/4PLCAAAAAElFTkSuQmCC X-Now-Playing: Hood's _Cold House_: "Lines Low To Frozen Ground" Date: Tue, 09 Aug 2022 19:23:10 +0200 Message-ID: <87o7wtwcu9.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> delete-dups is destructive. You can copy the list first, of course, but >> seq-uniq should be much faster than it is. > > How much faster? Using copy-sequence and delete-dups is 7 times > faster he [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> delete-dups is destructive. You can copy the list first, of course, but >> seq-uniq should be much faster than it is. > > How much faster? Using copy-sequence and delete-dups is 7 times > faster here than seq-uniq and twice faster than > gnus-delete-duplicates. I didn't claim that seq-uniq will be faster than copy + delete-dups; I just said that it's unnecessarily slow. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 13:36:51 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 17:36:51 +0000 Received: from localhost ([127.0.0.1]:44818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLT9v-0005ZT-Fc for submit@debbugs.gnu.org; Tue, 09 Aug 2022 13:36:51 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40364) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLT9u-0005ZH-98 for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 13:36:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44086) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLT9o-00076X-U1; Tue, 09 Aug 2022 13:36:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=+d1/oKtAiu7IGcxX7Ur1fatGzMgeQipJWevqa+RJDhY=; b=Led15/dcjWAf BjS83kaeI2Lg4tMBc+0FIHtLeppJK/Ufsl2+wCETiZZPxKYdNIe9SejxbPGnlRGIgf1D1x3uSvLs9 2Tz4DSSnAdMVTHnPFfAY/NWBGsA3eggTR22pVTOS2KymC5/4CM3FIFMtyM2AZ0qKFxKWhVlipxKIK 1VQ51UqfCwEbzLU6nNaXzqenHPgAmXbX/3Qed5hfM97ukI3vU1rHwRjKNJXRSiNmXvqV545tgTB8T ku9fBzk68CMgNfyzXV8uCzukCWldyULLEwRDaeQBIuBq4wvIQ2//Kwp21BMWh0PWiJLzLyz3wWFvs FJNhmhtklbalXr6SgqqTzw==; Received: from [87.69.77.57] (port=1246 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLT9o-0007tQ-DM; Tue, 09 Aug 2022 13:36:44 -0400 Date: Tue, 09 Aug 2022 20:36:34 +0300 Message-Id: <83fsi5tj31.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87o7wtwcu9.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 09 Aug 2022 19:23:10 +0200) Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: stefan@marxist.se, 57079@debbugs.gnu.org > Date: Tue, 09 Aug 2022 19:23:10 +0200 > > Eli Zaretskii writes: > > >> delete-dups is destructive. You can copy the list first, of course, but > >> seq-uniq should be much faster than it is. > > > > How much faster? Using copy-sequence and delete-dups is 7 times > > faster here than seq-uniq and twice faster than > > gnus-delete-duplicates. > > I didn't claim that seq-uniq will be faster than copy + delete-dups; I > just said that it's unnecessarily slow. But the above means that using seq-uniq with TESTFN nil is going to be unnecessarily slow from the get-go. People shouldn't use seq-uniq if they don't need a non-default TESTFN, because much faster implementations exist. IOW, since this bug is about speed, not anything else, I think making seq-uniq faster when TESTFN is nil isn't the right solution, the right solution is to point out that seq-uniq's purpose in this case is not to be a Speedy Gonzales. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 13:46:02 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 17:46:02 +0000 Received: from localhost ([127.0.0.1]:44833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLTIn-0005nK-20 for submit@debbugs.gnu.org; Tue, 09 Aug 2022 13:46:02 -0400 Received: from mail-vs1-f48.google.com ([209.85.217.48]:41556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLTIh-0005n0-Qs for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 13:45:59 -0400 Received: by mail-vs1-f48.google.com with SMTP id 129so12652011vsq.8 for <57079@debbugs.gnu.org>; Tue, 09 Aug 2022 10:45:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=eu/kx/H3fPE/gKALyv05iEzOoITtkA3fD/rkS9IcIro=; b=NVPWrimJdxmHS1sAEGrMefGTWmUYaiyZkFQVo2bAJWuUekm+4BVH+/CZngiyJvrZ8G 8kOb7ibmkJQbROFiixgJX5bV2l5REFylP+bEp+aU1mDDMJ1A8WETZyuYz1RBxAUGkbwq wJoS/6dH2IhakyG/ksxfJrpW5amKNCmQm0CgjgP+UU/OOdNEef6juDqQAWEonCXecuS4 jGJK5Eh5006p+z7AsJcVvb+OWX5pf084QOL2zMG5tWjtsT+MLkumDjfCfCcABoEBHwhE hbuclmtZSANZoTXrs9bU71AGQDSk3XxI2nCHMU0Ex+62VVHBJVsYf+9i9dGzK07I5lkM /pyw== X-Gm-Message-State: ACgBeo1UPloiQ7P1tBpLupGbVcHId/JOpmmf+vb78N1WmvHwzD/Py6WI SjGkw4GYTmv1DlORC6+EUiuaSc/04iAYVetdknI= X-Google-Smtp-Source: AA6agR4ae1NSrnIwQTlGImYyPsBNG5wKg25GMRoYMTOer0VhSAqZyIVOI9clr/bbKH6W8LKZSx95UKaUWhktVqjwwNI= X-Received: by 2002:a05:6102:7c6:b0:37d:34bd:8564 with SMTP id y6-20020a05610207c600b0037d34bd8564mr9878395vsg.59.1660067150389; Tue, 09 Aug 2022 10:45:50 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 9 Aug 2022 10:45:49 -0700 From: Stefan Kangas In-Reply-To: <87tu6lwcx7.fsf@gnus.org> References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83lerxtkfu.fsf@gnu.org> <87tu6lwcx7.fsf@gnus.org> X-Hashcash: 1:20:220809:57079@debbugs.gnu.org::YUjYHrrM9BDZAAnW:3+uX MIME-Version: 1.0 Date: Tue, 9 Aug 2022 10:45:49 -0700 Message-ID: Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good To: Lars Ingebrigtsen , Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Lars Ingebrigtsen writes: > Anyway, I've now made seq-uniq faster. This used to take 27 seconds, > and now takes 1.4s. Thanks! From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 13:50:32 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 17:50:32 +0000 Received: from localhost ([127.0.0.1]:44838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLTNA-0005wv-7D for submit@debbugs.gnu.org; Tue, 09 Aug 2022 13:50:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLTN8-0005wi-Du for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 13:50:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44340) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLTN1-0000nb-Cm; Tue, 09 Aug 2022 13:50:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=f6gVeHyZICzo/Rjk0Y1uTFVOJq6Ll8AAAls8Q5xVdG8=; b=SOuUqgwTEoye iIO410XGMXGZOXrUBwmdlwyIT0b7judG5QuBkbuw4r8QfRF8UVZoI+C4VQqQVPDUCJlAhR3oSDGCj WM4+z9GH0tve470cgmcm/JTRWA+5fPSfS1tUlBR9od7SvkxWOEJj+BJXRTEp7fKSus4hKClOinnWx FxdL7W/YZpZPEasz/hY8QKTPMJt7DVmzOxmhaNnyIsh7EntWUIOVzjYZucXxiNhkNG0m895iROEVK p4Ryz9mPcVxF7yTsbUXxtqqinBwfjMDK6sCojxQij+JzWTrNDNdsR+9Tg0M1hWVar093698UUib+f 7ocato9ee1kNgT6ZxUs0hg==; Received: from [87.69.77.57] (port=2078 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLTN0-0000hx-Rg; Tue, 09 Aug 2022 13:50:23 -0400 Date: Tue, 09 Aug 2022 20:50:11 +0300 Message-Id: <83czd9tigc.fsf@gnu.org> From: Eli Zaretskii To: larsi@gnus.org, stefan@marxist.se In-Reply-To: <83fsi5tj31.fsf@gnu.org> (message from Eli Zaretskii on Tue, 09 Aug 2022 20:36:34 +0300) Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 57079@debbugs.gnu.org, stefan@marxist.se > Date: Tue, 09 Aug 2022 20:36:34 +0300 > From: Eli Zaretskii > > But the above means that using seq-uniq with TESTFN nil is going to be > unnecessarily slow from the get-go. People shouldn't use seq-uniq if > they don't need a non-default TESTFN, because much faster > implementations exist. > > IOW, since this bug is about speed, not anything else, I think making > seq-uniq faster when TESTFN is nil isn't the right solution, the right > solution is to point out that seq-uniq's purpose in this case is not > to be a Speedy Gonzales. In particular, it means that this: commit 171b9314bf2b2ed1719f2451b527960e0a363a40 Author: Stefan Kangas AuthorDate: Tue Aug 9 14:29:12 2022 +0200 Commit: Stefan Kangas CommitDate: Tue Aug 9 17:58:15 2022 +0200 Replace utility functions with seq-uniq * lisp/gnus/gnus-util.el (gnus-delete-duplicates): * lisp/ibuf-ext.el (ibuffer-remove-duplicates): Redefine as obsolete function alias for 'seq-uniq'. Update callers. is incorrect: those callers should have been replaced with a faster implementation than seq-uniq could ever become. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 13:53:04 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 17:53:05 +0000 Received: from localhost ([127.0.0.1]:44842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLTPc-00060v-Mx for submit@debbugs.gnu.org; Tue, 09 Aug 2022 13:53:04 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLTPZ-00060P-5U for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 13:53:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=f+tw9+7b/bB2t51uDUcFZjYytYVryCQdYLbnW0MDiVQ=; b=tmeBO8Q/YnhADJ9Txr3WeTVZeX 669CG1bo0EIfHvz2wmVjlLLCPk5ahjiQnIEtTSSla1fTVoJfD3KbeTu5FvekeubqC9UEr0mNlRBGR UkyOL1q3ZN7BKhmeqNmXUWz62vH8Xqc3d3nC9fQuk0qaFR599VpPqIeD9O/zGK5mF+OE=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oLTPQ-0006F4-GB; Tue, 09 Aug 2022 19:52:54 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <83fsi5tj31.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 09 Aug 2022 20:36:34 +0300") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEUKBAcjFitoYmSF foAoK2EmR5YnWqomWaz////PNYGJAAAAAWJLR0QIht6VegAAAAd0SU1FB+YICRE0A352PX4AAAF4 SURBVDjLlZNRbsMgDIaLtAOEigOscIKRHaCRoO+VMDsB5AIrXH92CIoTNQ/zQx74+G3z27lc/h9X o/Wn1vZm7Giv2hpj9bgAbfTNGvtlRv2Nl4y20nSVPMkmMQb6vDlfY3cuzsB2PJxmOlEo6eSxhKPw wTmWTahJOYCYAMPdWSa6m3Othci0AYUA5oqRURSGN6CWfAB+BbWkMHEAHdQEHHjsaQUZ3F4R567Y iiwAclccwVqFA9lAbF3BZoqgdpsE387bRe8I5EJuTeyBeL9p0FxKJDqASIceswxCIVBDBy08pheO ufuxHM8lPJ4XGZ9sUA+yO9aXm4Svv2yEngDMLyfVD2LW1pIrlkCgwjZcsfQKOQWPILCpq0ZiLXN9 sRF2CZnCbd8A+VhOFNgVX9K1BvnL3MUgd2PKVIKvIraFNrZdTLwEPTG1RHyAHbTSByB86qsV7nvQ u83hoMgrgT1Y+l3CTXsFLSktw3T4d2XbH3AO/1BcFZL9AU2AuNk9yzc1AAAAJXRFWHRkYXRlOmNy ZWF0ZQAyMDIyLTA4LTA5VDE3OjUyOjAzKzAwOjAwUiA95QAAACV0RVh0ZGF0ZTptb2RpZnkAMjAy Mi0wOC0wOVQxNzo1MjowMyswMDowMCN9hVkAAAAASUVORK5CYII= X-Now-Playing: Grace Jones's _Warm Leatherette_: "Love Is The Drug" Date: Tue, 09 Aug 2022 19:52:51 +0200 Message-ID: <87k07hwbgs.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > But the above means that using seq-uniq with TESTFN nil is going to be > unnecessarily slow from the get-go. People shouldn't use seq-uniq if > they don't need a non-default TESTFN, because much fas [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > But the above means that using seq-uniq with TESTFN nil is going to be > unnecessarily slow from the get-go. People shouldn't use seq-uniq if > they don't need a non-default TESTFN, because much faster > implementations exist. > > IOW, since this bug is about speed, not anything else, I think making > seq-uniq faster when TESTFN is nil isn't the right solution, the right > solution is to point out that seq-uniq's purpose in this case is not > to be a Speedy Gonzales. I didn't make seq-uniq faster just when TESTFN is nil -- I made it faster for all lists, so I don't follow you at all here. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 13:59:21 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 17:59:21 +0000 Received: from localhost ([127.0.0.1]:44856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLTVh-0006AB-2J for submit@debbugs.gnu.org; Tue, 09 Aug 2022 13:59:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLTVf-00069y-52 for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 13:59:19 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44440) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLTVZ-0002F9-T9; Tue, 09 Aug 2022 13:59:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=nhMfCuPRR8X1+u5kxTg6bINt900MLNHZ+gcwNyMqmrU=; b=AalWQkl/Lfuv 1vOwC1xR4dd9n9WEIuzRtOUcKqTi1EthCQ0aVR8TvWJFo7+4KwhdmBEv3oFNOby1/S+tMlLbs326U sBpgmcFYRK8WnvtBQsrfmfptKKKJpS80BZfS9P78U0C1Zvmg3+qoWgMXaYxCmOqfnxuvxwQlVQKL4 +9Hn6R3O8BmYOxZhaGxw5XJcdjjNcpQi3Km/mbhvl5E0zqiYqIlFwTd89eiY/zZ7hf7Yj1kMqqMZR 4HcsmfsAKvFceSAlGkv9rzilU1tRCmbWw4re4INFSFT5r3yxMYWTBJIpnHhXGpBgNXlhpaVv5aG/K oAyZ+hiLru20L/AHgL5+NA==; Received: from [87.69.77.57] (port=2631 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLTVZ-0006ed-Br; Tue, 09 Aug 2022 13:59:13 -0400 Date: Tue, 09 Aug 2022 20:59:03 +0300 Message-Id: <838rnxti1k.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87k07hwbgs.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 09 Aug 2022 19:52:51 +0200) Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: stefan@marxist.se, 57079@debbugs.gnu.org > Date: Tue, 09 Aug 2022 19:52:51 +0200 > > Eli Zaretskii writes: > > > But the above means that using seq-uniq with TESTFN nil is going to be > > unnecessarily slow from the get-go. People shouldn't use seq-uniq if > > they don't need a non-default TESTFN, because much faster > > implementations exist. > > > > IOW, since this bug is about speed, not anything else, I think making > > seq-uniq faster when TESTFN is nil isn't the right solution, the right > > solution is to point out that seq-uniq's purpose in this case is not > > to be a Speedy Gonzales. > > I didn't make seq-uniq faster just when TESTFN is nil -- I made it > faster for all lists, so I don't follow you at all here. My point is that it will never be as fast as the implementations Stefan deleted, replacing them with seq-uniq. My point is that those changes just made several places in Emacs slower, even after your speedup, for no good reason. Those deleted functions, if they needed to be deleted, should have been replaced by a different implementation, which doesn't support TESTFN and is therefore faster, as the original implementations, now deleted, were. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 14:04:05 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 18:04:05 +0000 Received: from localhost ([127.0.0.1]:44860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLTaG-0006Il-SC for submit@debbugs.gnu.org; Tue, 09 Aug 2022 14:04:05 -0400 Received: from quimby.gnus.org ([95.216.78.240]:52288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLTa7-0006I9-Uz for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 14:04:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=z3uoTsf8l66jsDOHfatnL/OO0FOn/WDRLYgz/UM3hB0=; b=SaP+k+A/Phkt12ox12s0phDuW2 QUAewnBmLgoDIdTt0fpLAeWTElucuKINaEB/9zrMEqMekw7tvXt/RnsVt3T2rHVcrbXAs3phTKaYq TlrEQXqBUYA4lars9IQPDFViomq7Jbiqjys1+vLhdPg1cG9wDaK0bE2RGYE8QgunVMIQ=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oLTZy-0006Kf-VU; Tue, 09 Aug 2022 20:03:49 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <838rnxti1k.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 09 Aug 2022 20:59:03 +0300") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEUKBAcjFitoYmSF foAoK2EmR5YnWqomWaz////PNYGJAAAAAWJLR0QIht6VegAAAAd0SU1FB+YICRE0A352PX4AAAF4 SURBVDjLlZNRbsMgDIaLtAOEigOscIKRHaCRoO+VMDsB5AIrXH92CIoTNQ/zQx74+G3z27lc/h9X o/Wn1vZm7Giv2hpj9bgAbfTNGvtlRv2Nl4y20nSVPMkmMQb6vDlfY3cuzsB2PJxmOlEo6eSxhKPw wTmWTahJOYCYAMPdWSa6m3Othci0AYUA5oqRURSGN6CWfAB+BbWkMHEAHdQEHHjsaQUZ3F4R567Y iiwAclccwVqFA9lAbF3BZoqgdpsE387bRe8I5EJuTeyBeL9p0FxKJDqASIceswxCIVBDBy08pheO ufuxHM8lPJ4XGZ9sUA+yO9aXm4Svv2yEngDMLyfVD2LW1pIrlkCgwjZcsfQKOQWPILCpq0ZiLXN9 sRF2CZnCbd8A+VhOFNgVX9K1BvnL3MUgd2PKVIKvIraFNrZdTLwEPTG1RHyAHbTSByB86qsV7nvQ u83hoMgrgT1Y+l3CTXsFLSktw3T4d2XbH3AO/1BcFZL9AU2AuNk9yzc1AAAAJXRFWHRkYXRlOmNy ZWF0ZQAyMDIyLTA4LTA5VDE3OjUyOjAzKzAwOjAwUiA95QAAACV0RVh0ZGF0ZTptb2RpZnkAMjAy Mi0wOC0wOVQxNzo1MjowMyswMDowMCN9hVkAAAAASUVORK5CYII= X-Now-Playing: Grace Jones's _Warm Leatherette_: "The Hunter Gets Captured By The Game" Date: Tue, 09 Aug 2022 20:03:46 +0200 Message-ID: <878rnxwayl.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > My point is that it will never be as fast as the implementations > Stefan deleted, replacing them with seq-uniq. My point is that those > changes just made several places in Emacs slower, even after [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > My point is that it will never be as fast as the implementations > Stefan deleted, replacing them with seq-uniq. My point is that those > changes just made several places in Emacs slower, even after your > speedup, for no good reason. Those deleted functions, if they needed > to be deleted, should have been replaced by a different > implementation, which doesn't support TESTFN and is therefore faster, > as the original implementations, now deleted, were. The performance of the new seq-uniq (called with no TESTFN) is identical to the old gnus-delete-duplicates -- it's the same code. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 14:17:16 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 18:17:16 +0000 Received: from localhost ([127.0.0.1]:44866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLTn2-0006cD-D9 for submit@debbugs.gnu.org; Tue, 09 Aug 2022 14:17:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47870) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLTmz-0006by-8g for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 14:17:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44656) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLTmt-0004xs-Sw; Tue, 09 Aug 2022 14:17:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=J5HpsUv7+1DYS2NImmX3n8NP2+ERF4d8HMpDMC4B6Oc=; b=S8iG/N8BMheG SSPUCPuZ+I6He1mGYhWQ7oiX/bmUAGBRTr1k3vNpwYzS3JWdiJbkbnASoqtFxy6BlSN/OvquCxzN/ KYjs2S7enRLPPBR4p/rY3qoNtNh/TpfaNQIFFZrLGA1ECIVvU2MKiitolru/KuyPUvYe+ccnrqFAx Xfirk6v/erACq4daRUPwbIACfj1LaFomLNOo8Y7B5v6N9gnOqgPX3BlH52faS5LaI3MiLiVrWWjns /+L8BoimbX2Td39i+Ypm5Y8IG2CsqRl/5n5uvKet3J6u9+0AklpfXGuXNhsOvZrbQZL1zq3cuq0Lr dFtUmm/dV7rWwsiegoa31w==; Received: from [87.69.77.57] (port=3712 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oLTmt-0007gW-AI; Tue, 09 Aug 2022 14:17:07 -0400 Date: Tue, 09 Aug 2022 21:16:56 +0300 Message-Id: <837d3hth7r.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <878rnxwayl.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 09 Aug 2022 20:03:46 +0200) Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: 57079@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: stefan@marxist.se, 57079@debbugs.gnu.org > Date: Tue, 09 Aug 2022 20:03:46 +0200 > > Eli Zaretskii writes: > > > My point is that it will never be as fast as the implementations > > Stefan deleted, replacing them with seq-uniq. My point is that those > > changes just made several places in Emacs slower, even after your > > speedup, for no good reason. Those deleted functions, if they needed > > to be deleted, should have been replaced by a different > > implementation, which doesn't support TESTFN and is therefore faster, > > as the original implementations, now deleted, were. > > The performance of the new seq-uniq (called with no TESTFN) is identical > to the old gnus-delete-duplicates -- it's the same code. Yes, and delete-dups on a copy is faster. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 09 15:37:19 2022 Received: (at 57079) by debbugs.gnu.org; 9 Aug 2022 19:37:19 +0000 Received: from localhost ([127.0.0.1]:45133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLV2U-0000Yt-OZ for submit@debbugs.gnu.org; Tue, 09 Aug 2022 15:37:18 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:38987) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oLV2S-0000Yd-Sn for 57079@debbugs.gnu.org; Tue, 09 Aug 2022 15:37:17 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 248EDFF807; Tue, 9 Aug 2022 19:37:07 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <837d3hth7r.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 09 Aug 2022 21:16:56 +0300") Organization: LINKOV.NET References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> <837d3hth7r.fsf@gnu.org> Date: Tue, 09 Aug 2022 22:35:54 +0300 Message-ID: <86mtcdnrad.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57079 Cc: Lars Ingebrigtsen , 57079@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> > My point is that it will never be as fast as the implementations >> > Stefan deleted, replacing them with seq-uniq. My point is that those >> > changes just made several places in Emacs slower, even after your >> > speedup, for no good reason. Those deleted functions, if they needed >> > to be deleted, should have been replaced by a different >> > implementation, which doesn't support TESTFN and is therefore faster, >> > as the original implementations, now deleted, were. >> >> The performance of the new seq-uniq (called with no TESTFN) is identical >> to the old gnus-delete-duplicates -- it's the same code. > > Yes, and delete-dups on a copy is faster. delete-dups is faster because its implementation uses the hash table. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 12 09:16:25 2022 Received: (at 57079) by debbugs.gnu.org; 12 Aug 2022 13:16:26 +0000 Received: from localhost ([127.0.0.1]:55920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMUWX-0006Pz-K7 for submit@debbugs.gnu.org; Fri, 12 Aug 2022 09:16:25 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMUWS-0006Pe-Uo for 57079@debbugs.gnu.org; Fri, 12 Aug 2022 09:16:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=VCNFaH2egy/UsDliSAjgQubo3l7BT8QBCOYMgGHjJGY=; b=GYpGzhOZO3th6lmrSBegPWusS3 24iyYwb7ClwJ8xJJyjeRB8KXWGbtfP/zzysl47fzDlj/NVRarXDrrUWEM9UmuRD3u4rEaI+EsoZkn 8d/H4i1wkfRO0vX06mFyLbU3BaY5EKYyyUEeA1FBImGqWak7TtOM7bohNW4zFKFT7Pzk=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oMUWI-0005Gj-Ay; Fri, 12 Aug 2022 15:16:12 +0200 From: Lars Ingebrigtsen To: Juri Linkov Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <86mtcdnrad.fsf@mail.linkov.net> (Juri Linkov's message of "Tue, 09 Aug 2022 22:35:54 +0300") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> <837d3hth7r.fsf@gnu.org> <86mtcdnrad.fsf@mail.linkov.net> X-Now-Playing: Two Nice Girls's _Chloe Liked Olivia_: "Rational Heart" Date: Fri, 12 Aug 2022 15:16:09 +0200 Message-ID: <878rntr49y.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > delete-dups is faster because its implementation uses the hash table. Good point. I've now made seq-uniq do the same, and this makes the test case go from 1.7s to 0.07s. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: Eli Zaretskii , 57079@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Juri Linkov writes: > delete-dups is faster because its implementation uses the hash table. Good point. I've now made seq-uniq do the same, and this makes the test case go from 1.7s to 0.07s. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 12 19:59:27 2022 Received: (at 57079) by debbugs.gnu.org; 12 Aug 2022 23:59:27 +0000 Received: from localhost ([127.0.0.1]:59247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMeYp-0002XY-Ed for submit@debbugs.gnu.org; Fri, 12 Aug 2022 19:59:27 -0400 Received: from mout.web.de ([212.227.17.12]:57367) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMeYk-0002XH-GK for 57079@debbugs.gnu.org; Fri, 12 Aug 2022 19:59:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1660348753; bh=VOQqp93dPmeIsRP649/bUTTlZD4xnVARUwKlJ1Jj4iw=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=SqtxDKepoHYtTqeRV+CpIERQC5ZVs2KhZ9z+dK3xslKfs6wjWn+tSQHC/O2pwA3Gt JGCBeUEnbWzUZmJwUKbU4thvf3FVj/iyitFlMjXZSAjZQhdIRAzmkurxOq5ymCwhas b9gejmP3zUGx0UQCISQhG6XFST/xuQjLZG29iHWs= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.57.248.18]) by smtp.web.de (mrweb105 [213.165.67.124]) with ESMTPSA (Nemesis) id 1MhWor-1nif6Q1Hgh-00ePd5; Sat, 13 Aug 2022 01:59:13 +0200 From: Michael Heerdegen To: Lars Ingebrigtsen Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <878rntr49y.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 12 Aug 2022 15:16:09 +0200") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> <837d3hth7r.fsf@gnu.org> <86mtcdnrad.fsf@mail.linkov.net> <878rntr49y.fsf@gnus.org> Date: Sat, 13 Aug 2022 01:59:11 +0200 Message-ID: <87lertnhdc.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:CCLvflEZ0x6EDmqJDYmwcQ/mguR63osuK1i8MBZFP65oTVxViHT NRNgdqPd3l12pwQ4o+7gOar8hZP68+3IvkG3s2s1NzY4xQCFwdsUciH4yuHF4AZOAqpLeUs h90kzQ3VpJ5m8V+R0HBLbS7mrC1fFJMnBlenGNZxzUqVv2s26/2hOZ4mSCnm/wrqZwqnRAO c97TkHxtGvk21cOmYPN0A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:AFv416cZQVk=:J97GGSCOjnrmGME6rtlDKo wrV0S/K1Zyui5yAC26/R9/1vexaqqrjXLArWq9LKEXjmTKV8VNr4l1jKVfm9LlNS0WMvhG3cP 8QMrfa5NbYJpcOvjmr7aACpaXBoFUjhBGuUSwCi/p3+0+zyVosXQOrMXCBf+9QK6ymcs9q4fV mjhXQIRsrEzOa2wUDsr8H/KLj4+/It048+LrLaUaGlHn7VXgsKoEMoF1sR2rOihEmakwKD+k8 WoxzDYO+zHuSoiCS7h5syrd5Wffc309oIvy6VxnKb1iqACzZFN13fRj1P7/aPHh5GDTXoFWic vDvYrIDjqKhpQkBIxbwJKqYYU2LcvFY7so7S64aK2AY3RtCQhAIikWYcRNiCnW4nwfGWZieMs Gju+J/7GeM78I1Vzm3XJW/XHcpCGdB7VXZfaYKgurf4KVjDZVz2tSzsoAFN54y8GGxTmuagB2 u0sJYu75/10ZLQhafqvHZYpohPS2FdMbepIvblMpuEVDTX15C2HqdQCzR5xetmuPvi2+Nrtom zecADbCG/1WrxZuhLeJQ+b1yt2DLoDB3sJH3H6mOC7Maz/6LexxiYemmWzFgsXHStCwntlQzY dTqJoQ35R0QfObGxZmo+UVKC578xtJv7fn99GRSa+oWjjf+4vLcLEvAT5+d+LRdTj5JbuM2AN 6Pd3800xePltfSW+ioaKdeP0jIYHLw/OjY6TwJqM44SAZ0+gIX4bHWV4m/+33EwXNx/RnKkN6 XYtgPO6IfBQ6H2eiCJZyceijqTUdgijd43UWgfLYOK4LxUTd022Lr+fsy9BA9DwuaKwomkNu8 koSodtGw7ncF1ZdkroTyn4nNhmmYkUdOH1GYLsOUP5ldEfOa7aF8glnvCsziGVMXqKHeAWICf cbeG3v86ZRDqC78kGO0Mrw9fhcmMRtw7WyjtmBFxaq1qGJ2U4Vc2cTSjDkejIq1E6HVEwIHg4 uUPmdBmX3ctA5xA+mwaIiDz9abf47CZ27wZd04uW/2xAWCIZ72YEEzFiK7tGPn4kBuhqAVm2u 2/0IzAWD8eBaxhUMU+gff9CsV6Qchi+9wGvnVygD84pZM9bqwZT3EZwDmcwICpIzoI1MSKgxe v2yzYgfBtiON2RebM4KnGnUT52vcrDZYsaGp0Q009w61nLSna121d2CUA== X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 57079 Cc: Eli Zaretskii , 57079@debbugs.gnu.org, stefan@marxist.se, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: > > delete-dups is faster because its implementation uses the hash table. > > Good point. I've now made seq-uniq do the same, and this makes the test > case go from 1.7s to 0.07s. Good. I think a large amount of non-standard test functions is of the form (lambda (x y) (TEST (F x) (F y))) where TEST is a standard test function (equal or eq) and F some function that CL calls key function. This case can still be supported using hash tables. So I think it could make sense to add support for an additional optional KEY argument. Michael. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 13 07:50:56 2022 Received: (at 57079) by debbugs.gnu.org; 13 Aug 2022 11:50:56 +0000 Received: from localhost ([127.0.0.1]:59849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMpfM-0001sX-6V for submit@debbugs.gnu.org; Sat, 13 Aug 2022 07:50:56 -0400 Received: from quimby.gnus.org ([95.216.78.240]:35944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMpfJ-0001sI-P1 for 57079@debbugs.gnu.org; Sat, 13 Aug 2022 07:50:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=durJQz7TpVxX94kfFak/AHQyXkYf3AdSI0ltinnu8t8=; b=fGRl0EW0avNOO7PM4ztCCIYlj2 2kHxDKr1Y/ch72DS1NHgPN7XCQK13Gwz0lmYHyspsmTsrggBkywVpHJom9ZZjEX6RXJUJJcRXecZI VYSwUHG2Mo7pArJKoFS3CDFkiNK4n4kOBuCRZq+QlJmVpgX0ImIqCYmRAql1xrySz2kw=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oMpfA-0007GR-QI; Sat, 13 Aug 2022 13:50:46 +0200 From: Lars Ingebrigtsen To: Michael Heerdegen Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <87lertnhdc.fsf@web.de> (Michael Heerdegen's message of "Sat, 13 Aug 2022 01:59:11 +0200") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> <837d3hth7r.fsf@gnu.org> <86mtcdnrad.fsf@mail.linkov.net> <878rntr49y.fsf@gnus.org> <87lertnhdc.fsf@web.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEU7MjeVWmXe1cr/ //9HfuA7AAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YIDQssKM4C7ZYAAAFLSURBVCjPTZFBbsIwEEX/ WEmksjJSsiBHyClsqek6SDYL1kUqOUXgBHRB11RKKuJTdmzHgBfWPM/4j/0H4FVc/I467KvhBWr1 Ao0CGS6IAFQ2wREwunsA/cwGRQAH9PNBRWiGvJktdlFzoH5usY9Nod2cUwQg70fSHwvg8wtbSsCZ LsWoL0/IAVIJysxzggLZEmYw4pbAwtC0xNSiFFOq05BikktKE8SYlCmHuD3atCh+8VRY3RJU76jH cMrvq9iMeyjvQNZCzB7eFBtocQovaBU4xjkMQimybLX+jpOoGHK6RG3qWmyyboxftp08Bvd9xpbZ vVI9SxCDovnI1kusQVvF7sLxLGSwyd2Fc4MHRTyExjkvXknQ/to7LpUw/Pv+unJ8SYOHjkPLd/7Y M7/MTvuMiePxMC2ZcqO9GreHQlacQsas2fms2DL8A0kSVvj+DBcIAAAAJXRFWHRkYXRlOmNyZWF0 ZQAyMDIyLTA4LTEzVDExOjQ0OjQwKzAwOjAw+OIotwAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0w OC0xM1QxMTo0NDo0MCswMDowMIm/kAsAAAAASUVORK5CYII= X-Now-Playing: Joni Mitchell's _Dog Eat Dog_: "Good Friends" Date: Sat, 13 Aug 2022 13:50:44 +0200 Message-ID: <87pmh4jraj.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Heerdegen writes: > I think a large amount of non-standard test functions is of the form > > (lambda (x y) (TEST (F x) (F y))) > > where TEST is a standard test function (equal or eq) and F some function > that CL call [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: Eli Zaretskii , 57079@debbugs.gnu.org, stefan@marxist.se, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Heerdegen writes: > I think a large amount of non-standard test functions is of the form > > (lambda (x y) (TEST (F x) (F y))) > > where TEST is a standard test function (equal or eq) and F some function > that CL calls key function. More importantly, we can use a hash table directly if TESTFN is `eq'/`equal'/`eql' (or other pre-defined hash table tests), but it didn't seem important enough. > This case can still be supported using hash tables. So I think it could > make sense to add support for an additional optional KEY argument. I think we're into cl-lib.el territory then -- seq doesn't do KEY. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 13 16:24:49 2022 Received: (at 57079) by debbugs.gnu.org; 13 Aug 2022 20:24:49 +0000 Received: from localhost ([127.0.0.1]:35215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMxgf-0005D7-0N for submit@debbugs.gnu.org; Sat, 13 Aug 2022 16:24:49 -0400 Received: from mout.web.de ([212.227.15.4]:50493) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMxgd-0005Cu-A8 for 57079@debbugs.gnu.org; Sat, 13 Aug 2022 16:24:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1660422280; bh=+/fLqnBDWQaZqpJjitEkdzYjlDBwwK79wwzKMKxzxlU=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=AX4yr6sMVr3gXoPw6BZEbo8xITjMXV9ps8jU7wxWUKNc1y5T2aRsYqWua44uNMRjY vGAX9uaH9/v5WjIGXLyhqySawTCmN0GEu6NQK5thrHMhcbKtFHthdmhbz11RsumMFc K/KHvHa5ZNO9awD8w7CdYSiGo+BCsgbRgPWkbOA4= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.57.248.18]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MhWop-1nkLYB1Ad1-00ePGg; Sat, 13 Aug 2022 22:24:40 +0200 From: Michael Heerdegen To: Lars Ingebrigtsen Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <87pmh4jraj.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 13 Aug 2022 13:50:44 +0200") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> <837d3hth7r.fsf@gnu.org> <86mtcdnrad.fsf@mail.linkov.net> <878rntr49y.fsf@gnus.org> <87lertnhdc.fsf@web.de> <87pmh4jraj.fsf@gnus.org> Date: Sat, 13 Aug 2022 22:24:38 +0200 Message-ID: <87wnbboprt.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:Lhe3lTY29SMlih2z6lTEgndVRypuGZnP3hkenSa5+9W9TDaibWP W4XTofp4VqLW/IsMsM6d+OjU2QAbDHkFfDky4g6OUZMvq4IU4MN0XWyvYYQYckExC0YGJqV Lji4s+7s9urGOBoeHkgWehyCXo3Lk3srXKpTXAFBItrJ1mIy/j2SzhzVE1xnXwjmJVVGlPR jkcZHgRzbsE4IrWOvlTAg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:sP+U/JApal4=:JX+419Lj8OSGczbV91ojn3 4WSL5zMIHPJn+wSKw8Gqb2/hnQ31T3S91cdrkPbRERaCSo/sGXxmJbUV9g2Pi+hb2g3faLrHZ HWINm+NBOhx1AgBeq55zogBVfeS7EpOXiMR/b8eQeQ9l5KrAHweTGIqtV8CJ8ysPVQ6RwxdZj GA8Cn+/xG+KSR3Wu1C6wdy1q2u70T+dOOsF0KKQES/yUKoyGEvkQewP/tFthnRaKjsS0nVIsD JKinYQXzXRKK9eAafFGX0zoN5ys53tQnOdr7xH3PvNZI9rcOxYq/lZxq51/rGu+DjUdBwqcCs z2Dnvc0E5XycN+qtshidNXqUsuBzmy72oSLJJu1AqHfq1n3zKtqmpLX1MlP+5ZuUg8S/sJ7e5 BWmchylQ53c9ryUDOZMLu8+XtD/kxPt47bgolYRs8TY5fIMr3o1tqE3F9L2ni3rMX0FePiC+i Fr0+929/VS/ISZqYXYqsB63Gyb+Gpy8tDWuYqLVMKHvYa8Bxw+vLbJZpof3OmWyhMCWD4f3OM IaTdRzkxygPdsBeMHwoAklE4YNdCCb1unVzzcpunuEJwHSQxuBouCT8t5rvhw/0L3pfH24TXW JNQlFvGcVUaRSNfoAcmTNHAPyizmzZRAvjtGYI1/5T80ldjqvqvm06P0HJDAyrddjwh4AITR7 HA0afHecg30cYL4cP8FbWhgnVasojOyTeto4qXEpCZQf6siJK3TZm38gEGsK9QwmdanDMK8B2 qI+UXF2tNHO3b+6+F2GX86RDzy+Z0GzFjvdmaNDZhKzStrjMtUBiblVYoIWCzbowzZjb88DSR d0ZwhIwLqWNOpyrxzqFTe4HNJto/jcFLRduQnw6VNuWuFDLlMkJ+mcmExiB6JFe+O2+nCzjy6 4JN7lirTTYDEMDu2suRckVjqqtxhvFRkfYZQPxC+6mJ0xYUE/XeJBrgI2h/+YrDMH2vUGJq28 MK5vdyEeFgVAYIIKnbkX0sAwed2Pw8//f2jpoEGue9TrWI7HQphzR2LLZeI0BiYVKFZdP1B15 Gu4/LCz2RPbUsq0m/AEI654rf13Xx2sXKGIKZdRhDhVWY62+j2NEp8nqZ2XKQcKTG2eh8xmwC Dzqs5v4uXBtIuaLkPk3sA0+wfHNhX0KidaDH34csrSgEOdhgnEOq+J+fA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57079 Cc: Eli Zaretskii , 57079@debbugs.gnu.org, stefan@marxist.se, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: > I think we're into cl-lib.el territory then -- seq doesn't do KEY. It would make lots of uses much faster, call it as you like, don't think about how it's used in CL, it makes sense to add it as functionality to this function - that's the important part. We can find a different interface if you prefer that, e.g. allow the test function to be (TEST F) or something like that. I have search for occurrences of `seq-uniq' in all elisp files on my computer, and nearly all non-standard tests fell into this class. That's why I think we should provide a way to use `seq-uniq' for such cases. I had not at all been inspired by CL. Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 15 02:40:03 2022 Received: (at 57079) by debbugs.gnu.org; 15 Aug 2022 06:40:03 +0000 Received: from localhost ([127.0.0.1]:40433 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNTlb-0000J0-6W for submit@debbugs.gnu.org; Mon, 15 Aug 2022 02:40:03 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55654) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNTlZ-0000IP-7A for 57079@debbugs.gnu.org; Mon, 15 Aug 2022 02:40:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=IP47DMfpIJT61ax07bKBbcxKz1wxInaE9SCy7LNfbns=; b=dnAg5Kdv2oPJRa96exaug514YD 1BodLAswHgrrHWrsWADotgb30TWF7n35jdswn29NXLhcbIPejytCg+gBz2gU0V2xElhTOl4GZ5c+B nRBpJ8rqeO/tvJ52qIg9VSrdCtU/B9qYF8VfCyaXclXHGt+1P/ZfSpCJd5vto1snoPIg=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oNTlQ-0004XV-9f; Mon, 15 Aug 2022 08:39:54 +0200 From: Lars Ingebrigtsen To: Michael Heerdegen Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <87wnbboprt.fsf@web.de> (Michael Heerdegen's message of "Sat, 13 Aug 2022 22:24:38 +0200") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> <837d3hth7r.fsf@gnu.org> <86mtcdnrad.fsf@mail.linkov.net> <878rntr49y.fsf@gnus.org> <87lertnhdc.fsf@web.de> <87pmh4jraj.fsf@gnus.org> <87wnbboprt.fsf@web.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEW6ub0TExZaWl// ///b7+IJAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YIDwYdNL6P7bMAAAHBSURBVCjPLZFBi9swFIQn Bpe174Ylp7CgkuRXJLklJ2M8QvZJNZsl9q9wDIF1T70obHNyCgrJ/so+byuQ4NPTG0kzAO3VMPPJ MY8ArqKUafgW6VBgo4yASRghqFfuPwQIm1VyYBZq5eYIh059CHDiY7BU/Bo/SDB3ZCqzHKGSXStV 7QjfyypSZFijD7V3r0lNbrd4d/q7w6QomNWQloztRM7mCbajaNfTUSuIjuK7YkGu4Zo86SvvS+7/ gAfro1I9zPnzLpfWPLI+8uZLyGUi11TcsgB1Un742IY1azBlc5sFbaDdA6cqX97aEdQOfW+WEAD7 DreFmeFFKqweMIV5xqxrJ/IPeaiZtnPVXse3nQpzGWI3XLXvoXZWD9/us/j1kcHtMt6jdojPysAV jcDh12JPDceYh8A8L8QFOH0RmE1/j75FWckmsNNSJ1v87ATQCoQbqEp+A1ykUiHRlRNw9djj2PIw wpcaNzQCxX5MoVwlVpL9PLscizerLF7cp+aAcJ/GA2L3oBiypp2n/8AjpX3KReAxpqCdXSpxoJdQ 4b19CiXRiHWN/TqdT6R5wtMezOw8kEAjiUu8Hubifhdp8i8Ngbq/aYpF5AAAACV0RVh0ZGF0ZTpj cmVhdGUAMjAyMi0wOC0xNVQwNjoyOTo1MSswMDowMDyZ7KQAAAAldEVYdGRhdGU6bW9kaWZ5ADIw MjItMDgtMTVUMDY6Mjk6NTErMDA6MDBNxFQYAAAAAElFTkSuQmCC X-Now-Playing: Prince's _Dirty Mind_: "Uptown" Date: Mon, 15 Aug 2022 08:39:51 +0200 Message-ID: <87tu6ec8nc.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Heerdegen writes: >> I think we're into cl-lib.el territory then -- seq doesn't do KEY. > > It would make lots of uses much faster, call it as you like, don't think > about how it's used in CL, it makes sense to add it [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: Eli Zaretskii , 57079@debbugs.gnu.org, stefan@marxist.se, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Heerdegen writes: >> I think we're into cl-lib.el territory then -- seq doesn't do KEY. > > It would make lots of uses much faster, call it as you like, don't think > about how it's used in CL, it makes sense to add it as functionality to > this function - that's the important part. We can find a different > interface if you prefer that, e.g. allow the test function to be > (TEST F) or something like that. My point is that the seq library doesn't do KEY, it only does TESTFN, presumably because the person who wrote it was inspired by functional languages. We have virtually all the same functions in cl-lib.el, and the inspiration there is from Common Lisp, so all those functions take KEY (and a dozen other keyword parameters). Myself, I'd prefer that virtually all the functions in seq.el take a KEY, too, but that's not what that library is. Adding KEY to just `seq-uniq' doesn't make sense from a library design standpoint. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 15 19:38:03 2022 Received: (at 57079) by debbugs.gnu.org; 15 Aug 2022 23:38:03 +0000 Received: from localhost ([127.0.0.1]:44332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNjek-0002Yc-ST for submit@debbugs.gnu.org; Mon, 15 Aug 2022 19:38:03 -0400 Received: from mout.web.de ([212.227.15.3]:38885) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNjeh-0002Y6-61 for 57079@debbugs.gnu.org; Mon, 15 Aug 2022 19:38:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1660606672; bh=SNdY45d3i/CWKaZ3VPLTblVvk9zW5UKPL4uKMvVnn58=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=iP6HtDmPYfXSmwpq2LYe+XsL/ern7amVK7CVdTqyp+zzdjWp27weBj6ShpnErW7Xd rZHWUpQyFNJ8B1Qa846AxRvVVMQVmAM1J7hOFokp0EaAsiEMhUM4Zwk/gsDFf1EcYX jKeCZD+0joPflXD61gK20B+JpB9WEXbeEtLsOq30= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.57.248.18]) by smtp.web.de (mrweb006 [213.165.67.108]) with ESMTPSA (Nemesis) id 1McZjd-1nnZUb0EYP-00cXrX; Tue, 16 Aug 2022 01:37:52 +0200 From: Michael Heerdegen To: Lars Ingebrigtsen Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <87tu6ec8nc.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 15 Aug 2022 08:39:51 +0200") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> <837d3hth7r.fsf@gnu.org> <86mtcdnrad.fsf@mail.linkov.net> <878rntr49y.fsf@gnus.org> <87lertnhdc.fsf@web.de> <87pmh4jraj.fsf@gnus.org> <87wnbboprt.fsf@web.de> <87tu6ec8nc.fsf@gnus.org> Date: Tue, 16 Aug 2022 01:37:50 +0200 Message-ID: <87pmh1axip.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:5xMXndBZhZ4G3BiMu2oj627ehU8w4VarY2sQdnds/3kUfLjYeEo M8MtKI2z3tTfmbu2ZJ15MQhzsWs6l+MIjel8rtgx2G3m/MW5eyt2LbPeQetn/1Z9TV15Sgg uWdRqi2IC5YCDn2xolCR4cyB+VCE49/RQPLrfc2KBKkL71ShiU2X9ZNA7lvmO+ElXq6pocL E5VXgUFiy05ZOEMwlFFfQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:uPg+RhbUmYQ=:Ia/1Q/maTa+271VaG275B+ +OfZuNb8iLKW9A71oEeAoZ0PjgsFUluZMHDTUFx+uGT5HWZllOQqihUCoIwFXbZjkOLd5gBrp lX9RIHBbmTrGQJc/TB0MOn/tt06jRE02Ct//7h7uYnVEiYeR1Ntf6WlZFRSUesneiXxs4Wk6u uQy/7wNjEBx9VtoBBTt181U70YdmCp4hzOAba7kWLTFRePP5xA829U3e4FkyF9ss7YE4RnqGv 8y/368rFHV4rJR+EWu7HaJBuP/0PPQ4kiu/lK55JjxQ8fFQqzCBVDGRxN9V18oAiHMUYzzk4D kqaPP0LCEa0gzIU/on9z6bDdHcXAUNifpHjDWBjg2qb/hTHWcsTu8GRqzF4NpEjkCeXxAErUv ugIDQW7R1NGqLCOivfIde9TWVL/EUBbzUPwuJNIlRTSFjVggyH/WELny1CO3QbKyM8Ap3yZJg PuXNkj0Hzce8GkusGMp4aMyFO3vwPMZEYpK9JCI3Sz7hp/QVsBh+8iCoIDRpSETyzSK/Kl0+F j/Jxl5KJZKY7bdsLn8kS5JcyboZVE22LMaaMzJeKHAftszXBIGfyrSZy/RU8BuJoToz1CI8Gl hx0CDnNqsaSkTd/sON6VWDrx9Ao1HpHmxBFJzGWv+qjBwErr+HwDM5jWlzpp1OjoBfTw+2CMI 7Km4WsB6GxpH64FfDATMC+BgCKARtuXwxozXJ3Nzyi+ndpgY100qPvrXXhDEl+7fWXQM+SAEz 18J6x3LD3lxtfyF3QLO8WO4HOPhzGiL1FgFY8UkxuDwuZKRG25adMs+r/LW0KFM0YfSfvueKs H9t6zWg5SEWxiBn0BBxwj/h3MrKBk8Wsu262I/gqyD87lGwG+rkm6n0uL5z8/TzWAK3WSJzIF QEeJdcIEZxAvDj2Hq0s8c4VznuC39qgyZhstalvtHKiJ9iD6Yb3sX0f4fCwxVLFG3EQ7EHfEa CRW+yUV7KRa3KMoSqJCmDBNosJFihmcnV3Y+dxogICBqIaUGM4lhD7P7EcvmWiTR41qYvh6wV FWHzWGy51zeu4oXyePojIhIFnUPAUz565/sR2G9NZn7czP9++JZDbMgzvvVlbfPqHsfMM2frK LKrd3Mp3Xa1LFzy8W4SOpxKVlB5WxVysxWF//NKu2WZIpZy7GZJXUZHOA== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57079 Cc: Eli Zaretskii , 57079@debbugs.gnu.org, stefan@marxist.se, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: > Myself, I'd prefer that virtually all the functions in seq.el take a > KEY, too, but that's not what that library is. Adding KEY to just > `seq-uniq' doesn't make sense from a library design standpoint. But it makes sense from the viewpoint of practical requirements. Half of all use cases will run much slower if we don't support this case. Practical requirements and efficiency are more important than a slippery as an eel design. I come from mathematics, I looked at the code usages and saw equivalence classes and projection functions hiding behind. I regret that I ever used the work "key function". It would be a bad design choice not to address all the situations where abstraction wrt equivalence classes makes sense and improves a library just because CL also does that. Or do you have an idea for a different design that addresses such cases? Simply ignoring them makes no sense. And I see a bigger (design) problem here: as you said, there is a large overlap between seq.el and cl-lib.el. Once we said we don't want to extend CL too much because it should be compatible with Common Lisp. That was one reason why seq.el had been started. When we now say that we can't implement something in seq.el, something that is a practical need, because it already exists in cl-lib, we have a problem: we will end with two incomplete and half baked solutions for sequence handling. People will then have to use both libraries to get efficient code and support for their use cases, merging functions from libraries in their code. This should not be our long-term objective. It would also be a very bad design, in the end, for Emacs. Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 17 07:01:36 2022 Received: (at 57079) by debbugs.gnu.org; 17 Aug 2022 11:01:36 +0000 Received: from localhost ([127.0.0.1]:49537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOGno-00024D-Gh for submit@debbugs.gnu.org; Wed, 17 Aug 2022 07:01:36 -0400 Received: from quimby.gnus.org ([95.216.78.240]:44312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOGnm-00023z-3a for 57079@debbugs.gnu.org; Wed, 17 Aug 2022 07:01:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=142+AZq8eO/uzKT1+5OTNg3wQjOzAqxF9GyhFPV2+j4=; b=SlQXd9vilroheW9seo6j5fltr+ krwyHFiCcmYg3bLDNkC/m+1lDt+KKfJAByH87mvlwYdNwslbg+SyivmEF8ukfZYoDCVNqSl8SB9Ik 7fiDR+P1BTxRQ7JwaB1LLtTMk8mVynu3sB2DIPmiEerf2in5JPpMQRjIfjiqsCvfIg0c=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oOGnZ-0008Dd-8G; Wed, 17 Aug 2022 13:01:27 +0200 From: Lars Ingebrigtsen To: Michael Heerdegen Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <87pmh1axip.fsf@web.de> (Michael Heerdegen's message of "Tue, 16 Aug 2022 01:37:50 +0200") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> <837d3hth7r.fsf@gnu.org> <86mtcdnrad.fsf@mail.linkov.net> <878rntr49y.fsf@gnus.org> <87lertnhdc.fsf@web.de> <87pmh4jraj.fsf@gnus.org> <87wnbboprt.fsf@web.de> <87tu6ec8nc.fsf@gnus.org> <87pmh1axip.fsf@web.de> X-Now-Playing: The Honeymoon Killers's _It's a Crammed, Crammed, Crammed, Crammed World!_: "Subtitled Remix" Date: Wed, 17 Aug 2022 13:01:20 +0200 Message-ID: <87fshvjfr3.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Heerdegen writes: > But it makes sense from the viewpoint of practical requirements. Half > of all use cases will run much slower if we don't support this case. > Practical requirements and efficiency are more importan [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: Eli Zaretskii , 57079@debbugs.gnu.org, stefan@marxist.se, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Heerdegen writes: > But it makes sense from the viewpoint of practical requirements. Half > of all use cases will run much slower if we don't support this case. > Practical requirements and efficiency are more important than a slippery > as an eel design. Well, history tells a different tale. > And I see a bigger (design) problem here: as you said, there is a large > overlap between seq.el and cl-lib.el. Once we said we don't want to > extend CL too much because it should be compatible with Common Lisp. We've dropped that argument a long time ago -- it's free-for-all-time in cl-lib.el. > That was one reason why seq.el had been started. When we now say that > we can't implement something in seq.el, something that is a practical > need, because it already exists in cl-lib, we have a problem: we will end > with two incomplete and half baked solutions for sequence handling. They're both fully baked, but use different design philosophies, catering to different audiences. Of course I think that all seq.el functions should have :key... and :test-not and :start and :from-end, but I come from a CL background. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 19 23:17:38 2022 Received: (at 57079) by debbugs.gnu.org; 20 Aug 2022 03:17:38 +0000 Received: from localhost ([127.0.0.1]:59453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPEzS-0006oF-IA for submit@debbugs.gnu.org; Fri, 19 Aug 2022 23:17:38 -0400 Received: from mout.web.de ([212.227.15.3]:36725) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPEzP-0006o0-Nh for 57079@debbugs.gnu.org; Fri, 19 Aug 2022 23:17:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1660965448; bh=cwnVgnv1YpKLWfb1yaJGbycWrGCb53tZC1Wj3AIuapo=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=Io44/dUIl2G4VaUDAc4uPUpQI95xHuoj9rCy8j0tCoU04otk3WYyIGv9sU4SM/mkM VAj1QJcvaYdeVCyets5Sq7f26lm2gKoZGugUk0AW5OheZQMR9iwHLTjmjwhyS3wtV6 tY5kQYRcV7SuPuN+kVFqy65C/ZXd0oSZt+fNnPqc= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from drachen.dragon ([84.57.248.18]) by smtp.web.de (mrweb005 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MNwfU-1onMTw0ytM-00OXIr; Sat, 20 Aug 2022 05:17:28 +0200 From: Michael Heerdegen To: Lars Ingebrigtsen Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <87fshvjfr3.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 17 Aug 2022 13:01:20 +0200") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> <837d3hth7r.fsf@gnu.org> <86mtcdnrad.fsf@mail.linkov.net> <878rntr49y.fsf@gnus.org> <87lertnhdc.fsf@web.de> <87pmh4jraj.fsf@gnus.org> <87wnbboprt.fsf@web.de> <87tu6ec8nc.fsf@gnus.org> <87pmh1axip.fsf@web.de> <87fshvjfr3.fsf@gnus.org> Date: Sat, 20 Aug 2022 05:17:26 +0200 Message-ID: <871qtby56h.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:ppZ83VxrpuuYjGtLE0jBy3/Dw8FlCVZt0h+akvpOY7pr6+kPXff wnOGHOUamsVwiRvogoH3HyA4GL69GDVm1I41bVbFDynCJn6h8PKw/W2DrofO+dgUjxAqGqG ixik59xxMVKTCNOmLJJ6iBMkFFZ+iJ1NLleu3RW3D/yRRVOCDXsP0mTwSKKuijkXU4O/ymK V9xxxv38MIo6B+LHXlEbA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Gfd0JbeGRjc=:MEVGNL/8Snj0hzj/DhzSeo IKk8SA6ekcV/87ukIoUfdNNcuSRn/w4Z4rqk80aftxF2jzMpj6dIQODRZBPcMTOP67st24Tu8 YzGNM1pcIe4M0SvKKbbqJCcmOijjsgXloMGFNi58wv+Apb72Wkq+h7jvCa1/BvdYYjah8R65k ttC9TUpIQ8Evg2GyEvaYKvg4leN9VMiGXHbgekOaISQSxW/y41vJtTFiDG6TSbi0ReQDavraW zLVERI67eVErKxetb2kcDh1JuliJKbq4k8G32jwaJKGI35epafgUzfY/tKGhu6QmDUyROxL9v I5bvJvcTgyz/UC+A4MY3lE2SI3EWL+w7kpJguy7S45jpBHEPRBej+H+KZYql6Vn9obEmGSNYk 7aqbDWCxDioB4dKbnbdD9X3VxuSBEPVyaYRe3J9WRLOE+nHeRRTjroz2MHYem4bTJVnbGtvfI nOnDIc+1RZcS3fLfSXWClHB39H85RSv+tARe7o/HZA50q4DMaw2zo2QkhjpFrkAlx29e+IcTC ToHsBSJE6ec+7M7V6fXUj/guPVSExjEf7XshU1jY1n8buKxEnIR1fcF1obai2474q3bTtIE/n 6nqLoJkt/H5V+qmyFqFtZXioxfN7Vj6ATj9bjE4KnlpXmJE/XMUB/Cn5pPfaI4Rqpvu5nUpd8 jdpfEkkj3n2C+cLaZ0qOvnwCQz3c68pXuVBNws2qfWYq9CtS2ROkvKEvsTauO0Ik49nM7O1MU 4pI0h9+QqaZQz4AtaQwN5Rj3Id2xM+CknxEVqswHyZldPWrzxr9MoMuGJsuFclumyEWQlxcQp GEGDqYpJIjTrVjiqFfP9Z4aoc2owZYPgqtSMdgffoIEf7HYYpYI/FntK5fW60ZiA/TKKKePZi X686iaBXJ35yZy5OcIyucdSoinEHzqthSl2n1k3TjNJX0pcBX/pbHC/QsWTLoR12N33uITgWL nNL/KrVgoOUCzB9m/BiW194U1hNFzom5PoLXbrpO2VtERmYPIWWy8BJRK0hSuwsfyvTh3f0nX 9ttlzqYm/qbJICKTKBuUzjruhz1Jcl7y8KYDT0GYZiM41kpCRZzqofiiDVDwrr5bcKRpRjKes UbtHnpFjzAukC8PtCoNthnnhbmoqWvrw+xJHc/cX1lPLD7tG3O77CMkQQ== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57079 Cc: Eli Zaretskii , 57079@debbugs.gnu.org, stefan@marxist.se, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Lars Ingebrigtsen writes: > > [...] Once we said we don't want to extend CL too much because it > > should be compatible with Common Lisp. > > We've dropped that argument a long time ago -- it's free-for-all-time in > cl-lib.el. Are we going to merge (or cherry pick) stuff from seq.el to cl-lib? Probably not, so let's disregard the idea that cl-lib will ever be a complete replacement for seq.el stuff. > They're both fully baked, but use different design philosophies, > catering to different audiences. Of course I think that all seq.el > functions should have :key... and :test-not and :start and :from-end, > but I come from a CL background. I don't think I get it/buy it. Could you explain (in theory, a yes/no question) why we should not support that use case in `seq-uniq' without saying the word "CL", and if you say "design", without comparing with the design of CL? If you can't: seq.el has lots of overlaps with other parts of Emacs. What is so special about CL that an overlap is not acceptable? Or what is special about this task that it is not possible to handle it in several places? Please remember: I don't think in the term of "key functions", and I don't want to introduce something like that to other seq.el functions, so here is no argument. I'll stop asking after this Email because we are going in circles - but so far I just don't find your argumentation conclusive. Actually, this `seq-uniq' function is a logical part of the yet-to-write set.el library. The task/semantics is: Find a subset containing exactly one representative from each class of the elements of a given set. But I guess this library would also not be allowed to solve this task? Why do we add and develop them then at all? Wouldn't it be better to improve and develop cl-lib further instead then? Serious question. TIA, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 20 05:19:36 2022 Received: (at 57079) by debbugs.gnu.org; 20 Aug 2022 09:19:36 +0000 Received: from localhost ([127.0.0.1]:59563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPKdj-0001G9-NA for submit@debbugs.gnu.org; Sat, 20 Aug 2022 05:19:35 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPKdi-0001Fy-Lh for 57079@debbugs.gnu.org; Sat, 20 Aug 2022 05:19:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=SkugN/2Qd6zUSFPucAFjdaxHEAbSRvafrzWaU7Be1qs=; b=qT0oH4gFdMhGRW1am/nU77eSlO GrTI7NT0VM2G3nopFZvLVjXCn6Sg6aNitPjOuNeoot2iLPHlrc9xvSwr8qRkt4nxg3Dhr58K5+h0v 3R7K2q0LSryuDB4AqurnIAvex0VmxB1V41rEcbYLUiFJx35ll5SnXVuVuCtJcKoCpxY8=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oPKdZ-00032G-OB; Sat, 20 Aug 2022 11:19:27 +0200 From: Lars Ingebrigtsen To: Michael Heerdegen Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good In-Reply-To: <871qtby56h.fsf@web.de> (Michael Heerdegen's message of "Sat, 20 Aug 2022 05:17:26 +0200") References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> <837d3hth7r.fsf@gnu.org> <86mtcdnrad.fsf@mail.linkov.net> <878rntr49y.fsf@gnus.org> <87lertnhdc.fsf@web.de> <87pmh4jraj.fsf@gnus.org> <87wnbboprt.fsf@web.de> <87tu6ec8nc.fsf@gnus.org> <87pmh1axip.fsf@web.de> <87fshvjfr3.fsf@gnus.org> <871qtby56h.fsf@web.de> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAFVBMVEX+/v7q4N7TwrRe gHi8qB/27Q3///9D3i1BAAAAAWJLR0QGYWa4fQAAAAlwSFlzAAALEgAACxIB0t1+/AAAAAd0SU1F B+YIExUqCutGpSIAAAFYSURBVDjLzZPBbsMwCIZJpt27Vr23SXNfTV5gMb6vlXn/VxnY2HWSXSfN VaWED/gBB4A/ON2HnMPe3qMbhhEvO3BCFDvedwDzcTsFA7hVuRVw3UgHyvaZN9LRE+FMfqZ1XTei QIGZPX2tpGeiqHaO87KS0ABOx1NTVzeWAAVLJUeORGaXXIFzyceJmRpAkvMpaNI3IlNQkFyewBnI G7WAX0B/LZhqREnFOdU5Ab8FD3i3iGjAgr+hrzUWkFwu0PFKJNpspHsDFlNaBQNyHUFla06w1kvv JfAp4Mwxy2tM0XoI0HqjAE9UlaRaSPXGQJGQXkO+GFDEjb0BoqtVUQO6OiX5l4h0u3V6i6+TSXc7 ZfeIDtGHUNqAPHheRqef6K22YY3IarhrL8wFayOpq3mQ1TiiPpk2wHA4oesGWabeHUa8d8PrYx/E RyLePiE57Lbwl93MavBPzg9nrrmV9TqjMAAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMi0wOC0xOVQy MTo0MjoxMCswMDowMDXOyWMAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjItMDgtMTlUMjE6NDI6MTAr MDA6MDBEk3HfAAAAAElFTkSuQmCC X-Now-Playing: Various's _Deathbomb Digital Singles Club Year 2_: "Fun Juice" Date: Sat, 20 Aug 2022 11:19:24 +0200 Message-ID: <87fshrqnkz.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Michael Heerdegen writes: > Are we going to merge (or cherry pick) stuff from seq.el to cl-lib? > Probably not, so let's disregard the idea that cl-lib will ever be a > complete replacement for seq.el stuff. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57079 Cc: Eli Zaretskii , 57079@debbugs.gnu.org, stefan@marxist.se, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Heerdegen writes: > Are we going to merge (or cherry pick) stuff from seq.el to cl-lib? > Probably not, so let's disregard the idea that cl-lib will ever be a > complete replacement for seq.el stuff. Why probably not? We used to limit ourselves to what was in Common Lisp when the library was called cl.el, but now that it's cl-lib.el, we've opened up the possibility of adding whatever we think is useful in Emacs. > If you can't: seq.el has lots of overlaps with other parts of Emacs. > What is so special about CL that an overlap is not acceptable? Or what > is special about this task that it is not possible to handle it in > several places? I'm just explaining why the design of seq.el is the way that it is: It's the way it is because the person who wrote it wanted a sequence library with a simple, extremely regular interface. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 20 11:13:22 2022 Received: (at 57079) by debbugs.gnu.org; 20 Aug 2022 15:13:22 +0000 Received: from localhost ([127.0.0.1]:33378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPQA5-0002ZR-UQ for submit@debbugs.gnu.org; Sat, 20 Aug 2022 11:13:22 -0400 Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:41164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oPQA1-0002ZG-Tp for 57079@debbugs.gnu.org; Sat, 20 Aug 2022 11:13:20 -0400 Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27KD51Zi020061; Sat, 20 Aug 2022 15:13:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2022-7-12; bh=tvld+lKTzOpqzD8go81e3t3mD0RN24Z62AQZ0Ylxfyo=; b=w1f8FGmhXTzbg3P6IuXep/tPKAc4xLw4csNg0fMPZtxNA/Wpy1gHls+7HHHMjLhEcnk1 5HSdB702TGOedBrOyKSOSoGP5YAYUkrb/KyL42C4yIhQmxkDllofZALyyn+59PJYShc3 Vat7QijEPhCp3tFq6AmFowY3jqKVqSCey3V3LVlETBBDDxyB3c8fnaXWwtRTMzhtlew+ XIo90OiwUmOf7lUKBUP9q8oZJWqiYSk01aMbkkTyK6OJuzkx5N/iDxDxxZgKkQcKVoqz Yd6OQUfv1ArNZcpNe+8NVwMdI7P5LR08wNPJE1ETk5BsWRkf91pi3LMIdwYqZJJOL6Yr eg== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3j3063r30y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 20 Aug 2022 15:13:16 +0000 Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 27K9MpZu040891; Sat, 20 Aug 2022 15:13:15 GMT Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2169.outbound.protection.outlook.com [104.47.58.169]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3j2p2711dn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 20 Aug 2022 15:13:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e4aO8jsDJTro1qfqMNtaiSVttRwMjQ69jKFGpx8kaa2HrXaErNCqzLhOAVhuZJwUZ6yJJGeum8XXjeiSs65UInYdfJl6zSZo1f2iNBT7ud1HTg2Tqwr4fqx5X+rZpp8e1WNK91SKZbbthQnKP2CjXilspf88c7o7WDbnavn+TesUTk8XJ6lqNaWZqz+mgMUPSnD2Xhp2pKDfkxXU3ocw88/OEusOiMcDF8ydg/aATfIQatlioqO7A+AL4nS2tTfzGCLzbgUdbH1Pbqz+5TetInWR5r1VmAr71463UTrbEobuPe2f5GJiD8kCbTLWGdJLGv/rDG2H9A2ZJkInSsBNaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tvld+lKTzOpqzD8go81e3t3mD0RN24Z62AQZ0Ylxfyo=; b=kUAcYYWA/TPbho83Tcc8UnP9mtMhO9uur449mRfDoHKebrjx6teiC44u1MElKOEVSzRDJJNE7ljqsVc8RU9ue7jtJyMq7pA/Zpkc4oy2Y3gAd9dNry9o79Q1gjO0+6qOCd1kwBKR6BKoOzP5buhWGQmK9io/FLfUCCSSm1Id8fik6H2155TwwuMS9a/xOpfcrkiktg7l4+aYCOI2lGvshZn221dSBcdgqaQARCGaae+OZikhYOUkkGRinc3gZvTPjaxrm08uO51y74y01lpFAx7dyTOH6BqwQIC5psAJYGyP0beHXgw8m3RH59XKG4eKUpLmLAd8AdrzzJ4ObbKc9Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tvld+lKTzOpqzD8go81e3t3mD0RN24Z62AQZ0Ylxfyo=; b=lQBBxbm5lCBSNdx2FVv9AxSXkE5hCnS+LxUqhtbHrEh0QUJFWnEr+YiIAKThvynC13XEKaC1XCgyvS73KWNaRUF0sRgS33Fd7toJFIUbh2Fl0WT/qrq26NwthUBFsYWms2Ie8lxdtHN88bO24tPxHSLEKZ80ffWnXOArqDJ+BP0= Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by BYAPR10MB3111.namprd10.prod.outlook.com (2603:10b6:a03:159::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5546.19; Sat, 20 Aug 2022 15:13:13 +0000 Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::570:ff21:c9e1:22f1]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::570:ff21:c9e1:22f1%2]) with mapi id 15.20.5546.018; Sat, 20 Aug 2022 15:13:13 +0000 From: Drew Adams To: Lars Ingebrigtsen , Michael Heerdegen Subject: RE: [External] : bug#57079: 29.0.50; Performance of seq-uniq is not very good Thread-Topic: [External] : bug#57079: 29.0.50; Performance of seq-uniq is not very good Thread-Index: AQHYtHYNDSp4kuHkJEyaU76OD3C1Kq235Bfw Date: Sat, 20 Aug 2022 15:13:13 +0000 Message-ID: References: <83tu6ltlcq.fsf@gnu.org> <87y1vxwe0y.fsf@gnus.org> <83k07htjxf.fsf@gnu.org> <87o7wtwcu9.fsf@gnus.org> <83fsi5tj31.fsf@gnu.org> <87k07hwbgs.fsf@gnus.org> <838rnxti1k.fsf@gnu.org> <878rnxwayl.fsf@gnus.org> <837d3hth7r.fsf@gnu.org> <86mtcdnrad.fsf@mail.linkov.net> <878rntr49y.fsf@gnus.org> <87lertnhdc.fsf@web.de> <87pmh4jraj.fsf@gnus.org> <87wnbboprt.fsf@web.de> <87tu6ec8nc.fsf@gnus.org> <87pmh1axip.fsf@web.de> <87fshvjfr3.fsf@gnus.org> <871qtby56h.fsf@web.de> <87fshrqnkz.fsf@gnus.org> In-Reply-To: <87fshrqnkz.fsf@gnus.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f5aa30a8-bc05-4797-9c7d-08da82be806a x-ms-traffictypediagnostic: BYAPR10MB3111:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9YgSzMWyQ5eg56Z6sMnMR/9kgJPAPY9f0p/L0rqaF0hZ13vakwC4MquE28q27TP66cAdDzDvYufpnGwWGUXN7mjtC8uOepo6LvRHpMbV35lHS/c7C+zJ5+Q5gTc9Khy0BNICt2tZU5Ug7wHs9S676jK5+6m9Dkveat07WEsezJHpyy0xhen4I98sIxfnMLK2gHFmLSD21tjyfMSjlM8/UQqrQNY4uxM6Gj9l4OO0TUM17iDT5CcRhax56KXGHaPHvdFZzLg7vV6LLDH7ZdZkqmRHeiwMi7VapBvpt4veWx1M91bELx36ESja11xtl2FYUOcxhbfvOt81VlRysInIzqRXGhmNflXco715BShYRPeKE+MQzTw0Dtvln5nzYU5hEFZc+AfPFP0lUSxv0evWjqaQo25poaI2BxDpgoq/R1ZErxrcJ9ESD8rq81dOfawcnYpK78wYCnRBJEdvvgveBDy5490wotEKZFO3Ae9PGrbBDG50CznAIrWksOJjp4lvuNh/0yRTrhNRmFY5LJTqZOLWMf1zMayg6zQ4aUMfZaZiQeR3LMl5LEVpDkP1a+GfqZo5SeXMj0k/az5mv/HfIkgOorU9jeyPKn2PUgAP2UM4yzAHJcW+zks84NUvum7eDoqeYKu8x/pbhXbhbpis88x0cBQTHhBX0k7WkMp78Ea3HmlLc0ZdWRjlvUezYxT+Yb4RWUF30XG5dizXlGwd4gM4aPUsNTraw/ePbysy2uixlQUSEN7jESk1dnpagefaWVemgLZBVmAY6haOP2eKLw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(396003)(366004)(346002)(376002)(39860400002)(136003)(186003)(83380400001)(38070700005)(86362001)(122000001)(38100700002)(76116006)(66946007)(66556008)(66476007)(66446008)(316002)(4326008)(64756008)(8676002)(110136005)(2906002)(54906003)(44832011)(55016003)(52536014)(4744005)(8936002)(5660300002)(71200400001)(26005)(478600001)(41300700001)(9686003)(33656002)(7696005)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?7qsFwGdRunvdjENgv94S2Qe4idxCAsc7scNDVP0CzfYNm9lRCX9yXheEbR3F?= =?us-ascii?Q?6UNiCfmfuNePUrfMU3uzgiit+M0rJl7yrKT1aYypptdzlfVJNrKywKD19LHT?= =?us-ascii?Q?9isMW1NOyeV6eTsW7w9N+f8HnIFGxSfVSDCvEvNjxzW9yhK2wLjVo1k9xSTd?= =?us-ascii?Q?jSwcAwRaKLfspDNFmhMq0T0nwbirFPfnuS8R3rV3Y6EGIPNmyJNztQH9MeJH?= =?us-ascii?Q?5+mQzZqEDfUgVkqPGytyKOfL4uReHuYoOJaGAUczMCQfdTSaYsPZpP0uuRdE?= =?us-ascii?Q?Xu/w7BVA72RcyWFSmQqOOaSL1kLup2C1b24f7B6v9kDOSKTkOCSgImsJHpyl?= =?us-ascii?Q?JNH/cwQQJc1u1Y6OUx9Gw6uzZ/BGnEehVez/YDR8OjCoY3ztqXDp15t9wj6c?= =?us-ascii?Q?XI9g+2vacAoVCjpIKNtC3nmvqWfUxqEZaY1Zu/Qg02VzguJwXOeRdYTRE9uo?= =?us-ascii?Q?3fWJ5EdZnuozi5K6dUKEhENUnw+LA+YilJAdtinz5cDOz67dY4YrHQRQ/drp?= =?us-ascii?Q?0UNcPGp+DdrkSY9Ahhlz4Vzt/lozqK6uv44v0gbZAwjJLyCOvJ0joDGeGHNP?= =?us-ascii?Q?oebH/C41SJ/fwFEjNM8kRvpPv74uZiJdiZq3o7+YRi0RKH8YsfoAo6dJdrPN?= =?us-ascii?Q?16f8yrDWssbsU8zmB35z07cHaujD3piA7IAIuQoNokCmTwbWC23Cwhyggcgp?= =?us-ascii?Q?EnrFEGYj1dgoRHU50qZjxMy4yaWDF774bXWRJ+qVw87AZ0NYx37AXP+SJ+WW?= =?us-ascii?Q?km+TLxkK8F25qxksw7yW1EjGwJnoWOP7Brl2qPViOTGFsh/WxvnzhBVfz3N2?= =?us-ascii?Q?ZbQ3GnJhMKAJK1RlFKycteIyTSG/ziMNRX0e6fT2o40eeRtrWG+yVX+NSAfw?= =?us-ascii?Q?jJCI13Zs9wz9u68jZ53IgMczJ4ju/AkNAkXYBZMljaJQT3ezMDKKu4nPHBme?= =?us-ascii?Q?8P0nH+FaIo4EllZzfyMVuR8Mt5OaRf1i5FI/2mLXdPuVKQLDHahkpcm+vBor?= =?us-ascii?Q?c9W/fMN/igzv+kpk5Rky7CJ4R8CCnJ/av7xS1yF42qc7JZZGYE9Rnn6s+6jX?= =?us-ascii?Q?a7zp46dszEDthtWYuI2MCQsfPmZARkdGDIC4eeZkCV9ByRsK+Xfd27ltC3DS?= =?us-ascii?Q?ZL2Fu48JTH34u7kbp+vcVe+lgHiTnfMHDmEhrCLVaCaEXE/9iRv+aZPVIG4u?= =?us-ascii?Q?v3jHNZIsjw3hw3eP+SK75MQSyCLi6FgnCxSEEnRRgZaCDmM2U5dS9HuqGZSE?= =?us-ascii?Q?J7/3M4qZCQttpZobNaaT/w+NojfEafV8KWawBtamGtETJESBNL12wZ+jHvEg?= =?us-ascii?Q?IhbbhgTS4FLUZ8S974HH17aD0jZ5ECVT6PjlA7gcGCmsL3exTVCeYbSZAXoJ?= =?us-ascii?Q?yfeuh9ovIE4xB07j1UlFG/63AtneJRuyBJkKbP4ttRhcYaSWvIqU9Ma038t5?= =?us-ascii?Q?L6uRN/7zKLfMT/wFhDZK4XRwSJAjM4Ep3hHHR8vbJMfb+c+pEGWYHjl4kgqn?= =?us-ascii?Q?d/AhQivBtI56VQns6XYNghQaqfqXYjSEA9DZNFv5se/qtOG/2RlRLsbmR6Ey?= =?us-ascii?Q?V9JgsUWH+8I+TZ1Aqtn1H2YJnfJVorNs7zcyeuaF?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f5aa30a8-bc05-4797-9c7d-08da82be806a X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2022 15:13:13.6058 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JG9o6pZZ6Y8IOaKxxNUQCCqANwft5IRMGEuBlnJ6o9I7TDIPiPXn3YYMuVg9zXobdW2qI21vK1F+F41tIXvvkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB3111 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-20_08,2022-08-18_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 phishscore=0 spamscore=0 mlxlogscore=852 suspectscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208200064 X-Proofpoint-GUID: xINRt-tvQCvO7n1qUq_DDfgiAuth7d99 X-Proofpoint-ORIG-GUID: xINRt-tvQCvO7n1qUq_DDfgiAuth7d99 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 57079 Cc: Eli Zaretskii , "57079@debbugs.gnu.org" <57079@debbugs.gnu.org>, "stefan@marxist.se" , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > We used to limit ourselves to what was in Common Lisp > when the library was called cl.el, but now that it's cl-lib.el, we've > opened up the possibility of adding whatever we think is useful in > Emacs. Why would/did you do that? Why isn't cl-lib.el reserved for Common Lisp compatibility code? An answer of, essentially, "because we've already made that mistake" isn't, IMHO, a reasonable reason to continue making it. "whatever we think is useful in Emacs" - seriously? Not intending/expecting flames. Just one opinion. Emacs Lisp could & should have a Common Lisp compatibility library. That was the original intention of cl.el, I believe, and that should still be an intention, regardless of where that lives. If cl-lib.el is now too far polluted to serve as that, then maybe consider moving stuff that does have that intention somewhere else. From unknown Sat Sep 20 07:50:24 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 18 Sep 2022 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator