GNU bug report logs - #37393
26.2.90; [PATCH] Speed up 'csv-align-fields'

Previous Next

Full log

Message #17 received at 37393 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Simen Heggestøyl <simenheg <at> gmail.com>
Cc: 37393 <at> debbugs.gnu.org, sdl.web <at> gmail.com
Subject: Re: 26.2.90; [PATCH] Speed up 'csv-align-fields'
Date: Sun, 15 Sep 2019 14:43:14 -0400

>> 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.

> I've also attached a new suggestion for speeding up the column width
> computation itself by eliminating another 'current-column'-call. I'm not
> too sure about its correctness yet, but it seems to work in a few tests
> I've done, and it sped up 'csv--column-widths' by a factor of 1.3–1.4.

Looks OK, but deserves a comment explaining that this computation of the
new `col-beg` using tab-width and char-width is there to avoid an
additional call to current-column (it's basically
a "fast-current-column" which gets its extra speed from doing the work
more incrementally, whereas current-column always starts counting from
BOL).

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.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.