unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: <tomas@tuxteam.de>
To: help-gnu-emacs@gnu.org
Subject: Re: Passing buffers to function in elisp
Date: Wed, 22 Feb 2023 06:30:18 +0100	[thread overview]
Message-ID: <Y/Woag56GgNgY0ww@tuxteam.de> (raw)
In-Reply-To: <87mt56hg4e.fsf@iki.fi>

[-- Attachment #1: Type: text/plain, Size: 2825 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

  parent reply	other threads:[~2023-02-22  5:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21 21:18 Passing buffers to function in elisp Petteri Hintsanen
2023-02-21 23:21 ` [External] : " Drew Adams
2023-02-22  5:35   ` tomas
2023-02-24 20:08     ` Petteri Hintsanen
2023-02-25  6:40       ` tomas
2023-02-25 11:23       ` Michael Heerdegen
2023-02-25 13:45         ` tomas
2023-02-25 18:31           ` Michael Heerdegen
2023-02-25 19:05             ` tomas
2023-02-25 23:52         ` Stefan Monnier via Users list for the GNU Emacs text editor
2023-02-27 20:44           ` Petteri Hintsanen
2023-02-28  5:37             ` tomas
2023-03-03 15:19             ` Stefan Monnier via Users list for the GNU Emacs text editor
2023-03-07 21:48               ` Petteri Hintsanen
2023-03-07 22:45                 ` Stefan Monnier
2023-03-08  5:38                   ` tomas
2023-09-06 19:05               ` Petteri Hintsanen
2023-09-06 21:12                 ` Stefan Monnier
2023-02-22  5:30 ` tomas [this message]
2023-02-23  9:34   ` Michael Heerdegen
2023-02-23  9:51     ` tomas
2023-02-23 16:19     ` Marcin Borkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y/Woag56GgNgY0ww@tuxteam.de \
    --to=tomas@tuxteam.de \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).