unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Performance of String Operations
@ 2009-10-11  6:41 Nordlöw
  2009-10-11 10:05 ` Xah Lee
                   ` (3 more replies)
  0 siblings, 4 replies; 6+ messages in thread
From: Nordlöw @ 2009-10-11  6:41 UTC (permalink / raw)
  To: help-gnu-emacs

Does Emacs contain append/prepend/concat functions for strings that
modify one of its (first) arguments (for side effects only)?

If so, why not?: Isn't such a function crucial to the performance of a
language, regarding that strings is such a common object type?

Or does the Emacs compiler optimize such things? Can I somehow
investigate how Emacs has optimized my lisp code?

/Nordlöw


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Performance of String Operations
  2009-10-11  6:41 Performance of String Operations Nordlöw
@ 2009-10-11 10:05 ` Xah Lee
  2009-10-11 14:40 ` Colin S. Miller
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 6+ messages in thread
From: Xah Lee @ 2009-10-11 10:05 UTC (permalink / raw)
  To: help-gnu-emacs

On Oct 10, 11:41 pm, Nordlöw <per.nord...@gmail.com> wrote:
> Does Emacs contain append/prepend/concat functions for strings that
> modify one of its (first) arguments (for side effects only)?
>
> If so, why not?: Isn't such a function crucial to the performance of a
> language, regarding that strings is such a common object type?
>
> Or does the Emacs compiler optimize such things? Can I somehow
> investigate how Emacs has optimized my lisp code?
>

Hi Nordlöw,

i don't quite understand your question.

> modify one of its (first) arguments

?

> (for side effects only)?

?

you mean modify a variable fed to the string function, or something
like that?

functional languages don't do that in general.

  Xah
∑ http://xahlee.org/^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Performance of String Operations
  2009-10-11  6:41 Performance of String Operations Nordlöw
  2009-10-11 10:05 ` Xah Lee
@ 2009-10-11 14:40 ` Colin S. Miller
  2009-10-11 15:38 ` Helmut Eller
  2009-10-11 17:29 ` Pascal J. Bourguignon
  3 siblings, 0 replies; 6+ messages in thread
From: Colin S. Miller @ 2009-10-11 14:40 UTC (permalink / raw)
  To: help-gnu-emacs

Nordlöw wrote:
> Does Emacs contain append/prepend/concat functions for strings that
> modify one of its (first) arguments (for side effects only)?
> 
> If so, why not?: Isn't such a function crucial to the performance of a
> language, regarding that strings is such a common object type?
> 
> Or does the Emacs compiler optimize such things? Can I somehow
> investigate how Emacs has optimized my lisp code?
> 
> /Nordlöw

Nordlöw,

do you mean instead of
(setq a (concat a b c))
you can use
(concat-inplace 'a b c)
?
I don't think lisp supports the second style.
To support it, either all strings have to be over-allocated,
or atleast have space after them for growth.

HTH,
Colin S. Miller



-- 
Replace the obvious in my email address with the first three letters of the hostname to reply.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Performance of String Operations
  2009-10-11  6:41 Performance of String Operations Nordlöw
  2009-10-11 10:05 ` Xah Lee
  2009-10-11 14:40 ` Colin S. Miller
@ 2009-10-11 15:38 ` Helmut Eller
  2009-10-11 17:29 ` Pascal J. Bourguignon
  3 siblings, 0 replies; 6+ messages in thread
From: Helmut Eller @ 2009-10-11 15:38 UTC (permalink / raw)
  To: help-gnu-emacs

* Nordlöw [2009-10-11 08:41+0200] writes:

> Does Emacs contain append/prepend/concat functions for strings that
> modify one of its (first) arguments (for side effects only)?

Emacs has buffers for fast insert/append/prepend.

> If so, why not?: Isn't such a function crucial to the performance of a
> language, regarding that strings is such a common object type?

The size of strings is constant an cannot be changed.
Strings are arrays.

> Or does the Emacs compiler optimize such things? Can I somehow
> investigate how Emacs has optimized my lisp code?

M-x disassemble

Helmut


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Performance of String Operations
  2009-10-11  6:41 Performance of String Operations Nordlöw
                   ` (2 preceding siblings ...)
  2009-10-11 15:38 ` Helmut Eller
@ 2009-10-11 17:29 ` Pascal J. Bourguignon
  2009-10-11 20:58   ` John A Pershing Jr
  3 siblings, 1 reply; 6+ messages in thread
From: Pascal J. Bourguignon @ 2009-10-11 17:29 UTC (permalink / raw)
  To: help-gnu-emacs

Nordlöw <per.nordlow@gmail.com> writes:

> Does Emacs contain append/prepend/concat functions for strings that
> modify one of its (first) arguments (for side effects only)?
>
> If so, why not?

Because.


> Isn't such a function crucial to the performance of a
> language, regarding that strings is such a common object type?

No, mutation is not crucial to performance.  On the contrary, it can
be detriemental.  Functional programming languages are often faster
than programming languages having mutation.


> Or does the Emacs compiler optimize such things?  

AFAIK, no.


> Can I somehow investigate how Emacs has optimized my lisp code?

Of course.  You've got the sources.



Notice however that emacs provides a data structure for efficient
modification, notably for big strings.  It is called a buffer.


For example:

(with-temp-buffer 
   (insert "hello world")
   (delete-region 1 2)
   (goto-char 1) (insert "H")
   (delete-region 7 8)
   (goto-char 7) (insert "W")
   (end-of-line)
   (insert "!")
   (buffer-substring (point-min) (point-max)))

--> "Hello World!"


-- 
__Pascal Bourguignon__


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Performance of String Operations
  2009-10-11 17:29 ` Pascal J. Bourguignon
@ 2009-10-11 20:58   ` John A Pershing Jr
  0 siblings, 0 replies; 6+ messages in thread
From: John A Pershing Jr @ 2009-10-11 20:58 UTC (permalink / raw)
  To: help-gnu-emacs

pjb@informatimago.com (Pascal J. Bourguignon) writes:

> Notice however that emacs provides a data structure for efficient
> modification, notably for big strings.  It is called a buffer.

One of the great ideas from the ancient origins of Emacs is the notion
of a "buffer" with its "gap"; I assume that this has carried forward to
today's C-based Emacs.

A buffer is a large, contiguous chunk of storage containing text, where
the text is broken up into two pieces -- the "front" and the "back" (if
there are technical terms for this, I don't know what they are).  The
front of the text occupies the first <N> characters of the buffer, and
the back of the text occupies the last <M> characters of the buffer.
The result is that there is a "gap" in the middle of the buffer.  E.g.,

    |the quick brown |.....gap.....|fox jumped over the dog.|

Frequently (but not always), things will be arranged so that 'point' is
at the gap: this makes insertion of text easy -- nothing has to be
shifted or moved; the inserted text simply gets laid down at the front
of the gap, appended to the "front" piece of what's already there.  If
you move the point somewhere else and start inserting text, there is an
internal routine that will "move" the gap so that it lines up with the
new position of point (actually, text is moved from one side of the gap
to the other).

Of course, a bunch of low-level functions need to be aware of the gap
(e.g., string searches), and there's a bunch of complex bookkeeping, but
this is all worth it for the avoidance of lots of string copying.

  -jp


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-10-11 20:58 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-11  6:41 Performance of String Operations Nordlöw
2009-10-11 10:05 ` Xah Lee
2009-10-11 14:40 ` Colin S. Miller
2009-10-11 15:38 ` Helmut Eller
2009-10-11 17:29 ` Pascal J. Bourguignon
2009-10-11 20:58   ` John A Pershing Jr

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).