Re: Passing buffers to function in elisp

[tomas]

On Tue, Feb 21, 2023 at 11:18:25PM +0200, Petteri Hintsanen wrote:
> Hello list,
> 
> 
> Alan J. Perlis said "A LISP programmer knows the value of everything,
> but the cost of nothing."
> 
> 
> I'm reading some bytes into a temp buffer, like so:
> 
>   (with-temp-buffer
>     (set-buffer-multibyte nil)
>     (insert-file-contents-literally filename nil 0 64000))
> 
> then I pass these bytes to functions for processing, like this
> 
>     (func1 (buffer-string))
> 
> or sometimes just part of them
> 
>     (func2 (substring (buffer-string) 100 200))
> 
> Now:
> 
> . does this generate garbage?  (I believe it does.)

It most probably does, but that will depend on the future
history of buffer and whatever func1 does with its arg.

If both are needed later, it isn't garbage (yet). They
become garbage once they aren't needed.

> . if there are many funcalls like that, will there be lots of garbage?
>   (I guess there will be.)

See above. See, the documentation of `buffer string' hints
that it is doing a copy. If you modify the string, the buffer
will stay the same and vice-versa. If that is what you want,
then go for it :-)

> . is this bad style?  (I'm afraid it is, hence asking.)

See above: it depends. If you want func1 to operate on the
buffer content, then you better pass it the buffer itself
(actually a reference to the buffer, but that's "details" ;-)
If you'd be surprised that func1 is able to change the buffer,
then better pass it a copy: `buffer-string' seems a good
way to do that.

> Is it better just to assume in functions that the current buffer is the
> data buffer and work on that, instead of passing data as function
> arguments?

That depends on your style and on the "contracts" you make
with yourself (and ultimately, of course, on what you are
trying to do: for each different purpose, some style will
be clearer/more efficient -- ideally both, but life and
things).

> [Why am I doing like this?  It is /slightly/ easier to write tests when
> functions get their data in their arguments.]

Then go for it. To accompany your nice Perlis quote above
I offer "Premature optimization is the root of all evil",
which is attributed to Donald Knuth (some say it was Tony
Hoare).

Keep an eye on things and be ready to notice whether it
is creating performance problems.

> Also: is it good idea to try to limit the number temp buffers
> (with-temp-buffer expressions)?  Or are they somehow recycled within the
> elisp interpreter?

Once the interpreter (well, it's a hybrid these days. Let's
call it the "run time") can prove they aren't needed, it
will get recycled, yes.

If you are curious, just invoke (garbage-collect) after you
have accumulated some. It will tell you what it found.

Cheers
-- 
t

signature.asc
Description: PGP signature