From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Simen =?UTF-8?Q?Heggest=C3=B8yl?= Newsgroups: gmane.emacs.bugs Subject: bug#37393: 26.2.90; [PATCH] Speed up 'csv-align-fields' Date: Tue, 17 Sep 2019 18:53:06 +0200 Message-ID: <5d810f73.1c69fb81.486b.2e0a@mx.google.com> References: <5d7a7b56.1c69fb81.c32f6.840d@mx.google.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="206883"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37393@debbugs.gnu.org, sdl.web@gmail.com To: Eli Zaretskii , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 17 18:54:12 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iAGjz-000rdn-8b for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Sep 2019 18:54:11 +0200 Original-Received: from localhost ([::1]:48658 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iAGjy-00026f-5Z for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 Sep 2019 12:54:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48251) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iAGjr-00025s-Hz for bug-gnu-emacs@gnu.org; Tue, 17 Sep 2019 12:54:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iAGjq-0001XZ-3q for bug-gnu-emacs@gnu.org; Tue, 17 Sep 2019 12:54:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44378) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iAGjp-0001XQ-W9 for bug-gnu-emacs@gnu.org; Tue, 17 Sep 2019 12:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iAGjp-000069-SS for bug-gnu-emacs@gnu.org; Tue, 17 Sep 2019 12:54:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Simen =?UTF-8?Q?Heggest=C3=B8yl?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Sep 2019 16:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37393 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 37393-submit@debbugs.gnu.org id=B37393.156873919732740 (code B ref 37393); Tue, 17 Sep 2019 16:54:01 +0000 Original-Received: (at 37393) by debbugs.gnu.org; 17 Sep 2019 16:53:17 +0000 Original-Received: from localhost ([127.0.0.1]:53199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iAGj6-0008Vw-SI for submit@debbugs.gnu.org; Tue, 17 Sep 2019 12:53:17 -0400 Original-Received: from mail-lj1-f181.google.com ([209.85.208.181]:34322) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iAGj4-0008Vc-9f for 37393@debbugs.gnu.org; Tue, 17 Sep 2019 12:53:15 -0400 Original-Received: by mail-lj1-f181.google.com with SMTP id h2so4315801ljk.1 for <37393@debbugs.gnu.org>; Tue, 17 Sep 2019 09:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:subject:in-reply-to:date:mime-version; bh=rf1pehGAd/vylkpjDBKw8MnqOPGhFrqPcWsliSccShg=; b=FCXVdiJIyL1dqgnuJ2Nqgp+p0S2V4H6A78gr3+eB5DaVGbJHxUojKYZREzKaF0rMKR pKvRAC+c0cDIpTfyVVxQ0p67ugJrE3AiAUP6UkNvYyh3B4x1L0L287amSJmh3Htehwow 1krjMSPMlKq1ReFoV+BIm3Lcs/7Yz29aUhULccNekT7S0YzzvI4JPGWRwiYK6rXJ1hl2 vSGOnYOp3Svi2Tqsya57qzbCBchMupm4N34MvjdphOw/MYnBQvbH/B8g67mdCinWFxdR 7AuMnAeapv5NVMR6HmVQqZS1Qa7nZHz8Sn92eSqfUS5P9kbOO0/gsJyaJH+isEaImmgv kE3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:subject:in-reply-to:date :mime-version; bh=rf1pehGAd/vylkpjDBKw8MnqOPGhFrqPcWsliSccShg=; b=ly/TfXty1j2iqx/nAYmOxeaC4Ky/0QoEAZ+k2cPBKPjeF+QTAIgm0CN0+gYOOvvGXc WJ8U+Rqoijc8Gae6P32/axjZRz0pNk4y2Ojgfs7NHRHCucAxWUHvYh+NiEVeMeeOSYi6 rhQsBfm+9FUMkDywhzDFjD10bfuqwop81Q+hVC+2NpEPdudfWDB0KxGEK7YLp3wj6BZj azsFFmlSvOeUzGjz8SDMeUl1pc445E2bkZVUlplrLKtNx3bJ+unoOzwNnNd7CH5kX/ij NEpjiQV8kv20bs/J7m2W4zS9jH+1g7Ylu/XOCqH7EImNXd6lciyo1J69QTC6h1pLqUqX G5HQ== X-Gm-Message-State: APjAAAUPfHR+Imoi4OtAuvd79nFjvI1A7ODwlSvp/Du3xRn4v37Y/Gjr KyB0JpmoTfeaZADMgpLPlAs= X-Google-Smtp-Source: APXvYqxd3VQDUiBo3mxYLxgI1hzqmpAaGEohjVhV9wYC5ZZzYSQrI4Nrx1jM6VXo8Akk1TwdnPsvPw== X-Received: by 2002:a2e:3613:: with SMTP id d19mr2415240lja.57.1568739188210; Tue, 17 Sep 2019 09:53:08 -0700 (PDT) Original-Received: from ae25 (cm-84.210.143.4.getinternet.no. [84.210.143.4]) by smtp.gmail.com with ESMTPSA id 134sm524544lfk.70.2019.09.17.09.53.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Sep 2019 09:53:07 -0700 (PDT) X-Google-Original-Message-ID: <87k1a6g8zx.fsf@simenheg@gmail.com> In-Reply-To: (message from Stefan Monnier on Sun, 15 Sep 2019 14:43:14 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:166650 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: > I'm talking here about something I don't understand well enough, but > did you try computing column width using vertical-motion? No, I haven't yet tried anything in that direction. Stefan Monnier writes: >>> If you're interested in this line, I think there are two avenues to >>> improve the behavior further: >>> - align lazily via jit-lock (this way the time is determined by the >>> amount of text displayed rather than the total file size). >> Wouldn't that still depend on knowing the column widths? > > Of the whole file? No: instead you'd only use the max of the columns that > you've seen so far. When it increases (thus invalidating > alignment-overlays already created), you just "flush" those overlays and > rebuild them. Wouldn't then the columns appear to jump about whenever a new max width is discovered? I also guess you'd lose the ability to do e.g. C-u 1000 C-n and stay in the same column? > Maybe we could get yet more speedup by making it possible to pass to > `current-column` (or a new C function) a start position along with its > column, so we'd avoid re-traversing the part of the line that we've > already processed. I think that sounds like a good idea; then my ugly "fast-current-column" patch from last time won't be needed. I have no prior experience with Emacs' C internals, but an initial naive attempt is attached. I've only tested it on some basic cases where it seems to behave correctly and gives a speedup factor of around 4,5x=E2=80=935x. Could this track be somet= hing worth exploring further? --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-WIP.patch >From 16d8915b8ad96b2aa7fb0350468b4af847c5ff19 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Simen=20Heggest=C3=B8yl?= Date: Tue, 17 Sep 2019 17:32:00 +0200 Subject: [PATCH] WIP --- src/indent.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/src/indent.c b/src/indent.c index 1b589a710c..f2c525d882 100644 --- a/src/indent.c +++ b/src/indent.c @@ -46,6 +46,10 @@ #define CR 015 ptrdiff_t last_known_column_point; +/* Value of point byte when current_column was called. */ + +ptrdiff_t last_known_column_point_byte; + /* Value of MODIFF when current_column was called. */ static modiff_count last_known_column_modified; @@ -325,6 +329,7 @@ DEFUN ("current-column", Fcurrent_column, Scurrent_column, 0, 0, 0, invalidate_current_column (void) { last_known_column_point = 0; + last_known_column_point_byte = 0; } ptrdiff_t @@ -454,6 +459,7 @@ current_column (void) last_known_column = col; last_known_column_point = PT; + last_known_column_point_byte = PT_BYTE; last_known_column_modified = MODIFF; return col; @@ -545,6 +551,17 @@ scan_for_column (ptrdiff_t *endpos, EMACS_INT *goalcol, ptrdiff_t *prevcol) ptrdiff_t scan, scan_byte, next_boundary; scan = find_newline (PT, PT_BYTE, BEGV, BEGV_BYTE, -1, NULL, &scan_byte, 1); + + if (scan < last_known_column_point + && end > last_known_column_point + && MODIFF == last_known_column_modified) + { + scan = last_known_column_point; + scan_byte = last_known_column_point_byte; + col = last_known_column; + prev_col = last_known_column; + } + next_boundary = scan; window = Fget_buffer_window (Fcurrent_buffer (), Qnil); @@ -701,6 +718,7 @@ scan_for_column (ptrdiff_t *endpos, EMACS_INT *goalcol, ptrdiff_t *prevcol) last_known_column = col; last_known_column_point = PT; + last_known_column_point_byte = PT_BYTE; last_known_column_modified = MODIFF; if (goalcol) @@ -848,6 +866,7 @@ DEFUN ("indent-to", Findent_to, Sindent_to, 1, 2, "NIndent to column: ", last_known_column = mincol; last_known_column_point = PT; + last_known_column_point_byte = PT_BYTE; last_known_column_modified = MODIFF; XSETINT (column, mincol); @@ -1040,6 +1059,7 @@ COLUMN (otherwise). In addition, if FORCE is t, and the line is too short last_known_column = col; last_known_column_point = PT; + last_known_column_point_byte = PT_BYTE; last_known_column_modified = MODIFF; return make_fixnum (col); -- 2.23.0 --=-=-= Content-Type: text/plain -- Simen --=-=-=--