From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen <larsi@gnus.org> Newsgroups: gmane.emacs.bugs Subject: bug#36566: 27.0.50; debug is sometimes horribly slow Date: Mon, 16 May 2022 03:00:45 +0200 Message-ID: <87h75qguki.fsf@gnus.org> References: <87r26yvb4r.fsf@web.de> <87v9tza6gg.fsf@gmail.com> <875zlvj453.fsf@runbox.com> <87bkwp2pjr.fsf@gnus.org> <87a6c72v1t.fsf@runbox.com> <87k0bb16jc.fsf@web.de> <874k2ed828.fsf@gnus.org> <875ym931t9.fsf@runbox.com> <87mtfl1kxt.fsf@gnus.org> <87h75s3gx8.fsf@web.de> <87pmkgl52s.fsf@gnus.org> <jwvk0aofcs4.fsf-monnier+emacs@gnu.org> <87lev4jeyq.fsf@gnus.org> <jwv5ym8hzvn.fsf-monnier+emacs@gnu.org> <87czggjdeo.fsf@gnus.org> <878rr4jbr3.fsf@gnus.org> <jwvtu9sgd33.fsf-monnier+emacs@gnu.org> <87r14vhtju.fsf@gnus.org> <jwv35hag4ie.fsf-monnier+emacs@gnu.org> <87pmkehifs.fsf@gnus.org> <jwvwnemd9pk.fsf-monnier+emacs@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27731"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Michael Heerdegen <michael_heerdegen@web.de>, Gemini Lasswell <gazally@runbox.com>, 36566@debbugs.gnu.org, Noam Postavsky <npostavs@gmail.com> To: Stefan Monnier <monnier@iro.umontreal.ca> Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 16 03:01:21 2022 Return-path: <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org> Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org>) id 1nqP6t-000726-Ux for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 May 2022 03:01:20 +0200 Original-Received: from localhost ([::1]:35864 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org>) id 1nqP6s-0003MF-GI for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 May 2022 21:01:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42288) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1nqP6c-0003LX-Qt for bug-gnu-emacs@gnu.org; Sun, 15 May 2022 21:01:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57174) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1nqP6c-00084B-IG for bug-gnu-emacs@gnu.org; Sun, 15 May 2022 21:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1nqP6c-0003cT-BZ for bug-gnu-emacs@gnu.org; Sun, 15 May 2022 21:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen <larsi@gnus.org> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org> Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 May 2022 01:01:02 +0000 Resent-Message-ID: <handler.36566.B36566.165266285913894@debbugs.gnu.org> Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36566 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 36566-submit@debbugs.gnu.org id=B36566.165266285913894 (code B ref 36566); Mon, 16 May 2022 01:01:02 +0000 Original-Received: (at 36566) by debbugs.gnu.org; 16 May 2022 01:00:59 +0000 Original-Received: from localhost ([127.0.0.1]:51071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces@debbugs.gnu.org>) id 1nqP6Z-0003c1-EP for submit@debbugs.gnu.org; Sun, 15 May 2022 21:00:59 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:36676) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <larsi@gnus.org>) id 1nqP6X-0003bm-L4 for 36566@debbugs.gnu.org; Sun, 15 May 2022 21:00:58 -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:In-Reply-To:Date: References: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=V16I9pDk76htLdEwOq3V5hM8AGE72uVI96o68FLVIgs=; b=l+7YrqAJsVVeXgboCBpItexLls Aw5AXZNgddrvMjSRj3GquGERnE5Oq2xC/3vFTVVxKlxWviTlV3OSglwyc5uBh5l9s0Kc+cWFOmDln JPtrqYrJ1Yc+b4EubgK3pwW2wrgqrWfjUbrzdvp7NDXp91q+r0r4n+kTpsH3R5NOUHNQ=; Original-Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <larsi@gnus.org>) id 1nqP6M-0007Sd-Lv; Mon, 16 May 2022 03:00:49 +0200 In-Reply-To: <jwvwnemd9pk.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Sun, 15 May 2022 12:52:44 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-gnu-emacs>, <mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/bug-gnu-emacs> List-Post: <mailto:bug-gnu-emacs@gnu.org> List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>, <mailto:bug-gnu-emacs-request@gnu.org?subject=subscribe> Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org> Xref: news.gmane.io gmane.emacs.bugs:232345 Archived-At: <http://permalink.gmane.org/gmane.emacs.bugs/232345> Stefan Monnier <monnier@iro.umontreal.ca> writes: > Maybe it would. I tend to think we should focus the C code on printing > data quickly and in a `read`able way (i.e. in sync with `lread.c`) and > benefit from the comfort of ELisp for the implementation of the > human-readable version of the printout where performance is not as > important because we will truncate long outputs anyway. Well, OK... but why does edebug use cl-prin1 then when stepping through code? Stepping through code should be fast, and we don't really care that much about the prettiness of the values were displaying then. Using cl-prin1 would is fine in `edebug-eval-expression' etc, but I don't quite see the point when stepping? So if we use prin1 when stepping, we could implement `char-length' purely as an OVERRIDE element, and not do that in cl-prin1. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no