[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [External] : Passing buffers to function in elisp
From: |
Petteri Hintsanen |
Subject: |
Re: [External] : Passing buffers to function in elisp |
Date: |
Tue, 07 Mar 2023 23:48:10 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Stefan Monnier via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:
> This is a typical a source of unnecessary O(N²) complexity: the above
> line takes O(N) time, so if you do it O(N) times, you got your
> N² blowup. You're usually better off doing
>
> (push (plist-get page :stream) stream-chunks)
>
> and then at the end get the `stream` with
>
> (mapconcat #'identity (nreverse stream-chunks) nil)
> or
> (apply #'vconcat (nreverse stream-chunks))
Right, I see. Stream chunks are in this case byte vectors, so
just reversing those chunks does not do the trick.
But surely I can get from an order of N² to 2N or so.
> Of course that depends on what else happens with `stream` (I haven't
> really looked at your code, sorry).
It's ok, I'm not expecting any reviews here. All these comments from
you and others have been valuable already.
>> No, it was not byte-compiled.
>
> Then stop right there and fix this problem. There's absolutely no point
> worrying about performance (including memory use) if the code is
> not compiled because compilation can change the behavior drastically.
>
> The only reason to run interpreted code nowadays is when you're
> Edebugging a piece of code.
Okay, this is something I did not foresee. But what about eval-defun
and eval-... in general? They are very convenient when trying out
things. Should I bind compile-defun to C-M-x then? And instead of
eval-buffer use byte-compile-file? Or emacs-lisp-byte-compile-and-load?
Manual is a bit spotty here; emacs-lisp-byte-compile-... functions are
not mentioned.
>> I'll try byte-compiling after the code is in good enough shape to do
>> controlled experiments.
>
> The compiler is your friend. He can help you get the code in good shape :-)
I'm afraid that even the compiler cannot help against quadratic
complexity blunders. But I think I got your point.
Thanks,
Petteri