Performance of String Operations

Performance of String Operations

[Nordlöw]

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

Re: Performance of String Operations

[Xah Lee]

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/

☄

Re: Performance of String Operations

[Colin S. Miller]

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.

Re: Performance of String Operations

[Helmut Eller]

* 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

Re: Performance of String Operations

[Pascal J. Bourguignon]

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__

Re: Performance of String Operations

[John A Pershing Jr]

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