GNU bug report logs - #68072
pp functions have O(n^2) runtime with lisp-indent-function set to common-lisp-indent-function

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Brennan Vincent <brennan <at> umanwizard.com>, 68072 <at> debbugs.gnu.org
Subject: bug#68072: pp functions have O(n^2) runtime with lisp-indent-function set to common-lisp-indent-function
Date: Fri, 5 Jan 2024 13:06:30 +0000

On Fri, Jan 5, 2024 at 3:50 AM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>
> > And Eglot should probably use a faster pretty printer than the default
> > `pp` for that.  Maybe we should make `lisp-data-mode` set
> > `pp-default-function` or `lisp-indent-function` to avoid such problems?
>
> Jsonrpc uses the pretty printer via `pp-to-string` so there's no major
> mode to change (and `pp-to-string` isn't told whether it's printing code
> or data 🙁), and in order to run on older Emacsen it can't really use
> the `pp-function` argument either.
>
> So in the mean time, maybe the patch below is in order?
> João, any comment?

Maybe, I think so.

Though the starting premise of this bug:

> This also causes eglot (in its default configuration) to hang when
> opening large Rust files, since rust-analyzer tends to send large amounts of
> inlay hints, and eglot logs the messages it receives as pretty-printed
> lisp objects.

Is not true anymore, starting around the time Brennan opened it.
Eglot now uses JSON by default, which should solve most of the
performance  issues related to logging.

But Lisp pp is still opt-in, and making it faster (and relatively
pretty) is a good thing.

João

Previous Next

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