help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: efficiency question on text manipulation using string vs buffer


From: Xah Lee
Subject: Re: efficiency question on text manipulation using string vs buffer
Date: Tue, 24 Mar 2009 19:56:34 -0700 (PDT)
User-agent: G2/1.0

On Mar 24, 7:34 pm, Kevin Rodgers <address@hidden> wrote:
> Xah Lee wrote:
> > emacs lisp question.
>
> > it's said that for text manipulation, operation on buffer data type is
> > more efficient than operation on string data type.
>
> > today, i tried to test it, but the difference seems negligible ? My
> > tentative test seems to indicate, that after performing 120 thousand
> > string replacement, the string method is only 1 second slower.
> ...
> > It appears to me, testing these commands on a text selection with
> > about 122k chars that needs to be replaced, the second version is only
> > 1 second slower? (both finishes within 2 or 3 seconds, on a 2007
> > midrange PC)
>
> > Any comments?
>
> The version that takes 3 seconds is 50% slower than the version that
> takes 2 seconds.

LOL Kevin. I think with what little skills i have, i can still do
arithmetic fine.

The point is, the speed difference is few micro seconds for all
practical purposes, at least this particular code comparison.  (the
version with save-restriction and narrow-to-region might even be
slower if the function is called multiple times for its overhead.)

I like the version that repeated sets var and repeatedly call replace-
regexp-in-string. This is conceptually simple and the concept is
universal among langs. The version calling save-restriction and narrow-
to-region is emacs specific, requires some specific knowledge about
emacs/lisp environment to understand.

i somewhat fear, if repeated or recursive call to save-restriction or
narrow-to-region or similar might break something. (don't fully
understand their details... which involves buffers, marks, etc.)

  Xah
∑ http://xahlee.org/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]