Re: [External] : Passing buffers to function in elisp

[Petteri Hintsanen]

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