guile-user
[Top][All Lists]
Advanced

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

SRFI-13 again [was: Re: string vs list processing]


From: Martin Grabmueller
Subject: SRFI-13 again [was: Re: string vs list processing]
Date: Tue, 17 Apr 2001 16:58:34 +0200

> From: Michael Livshin <address@hidden>
> Date: 16 Apr 2001 16:45:28 +0300
> 
> address@hidden (Bill Gribble) writes:
> 
> > Be smart about when you call string operations.  In Gnucash, we use
> > guile to assemble multi-megabyte HTML documents.  You can't go around
> > string-appending every "<" to "p>" to construct this size string; the
> > garbage you generate is ridiculous.  You will get much better
> > performance if you cons up a list of component strings, reverse it at
> > the end, and apply string-append to the whole list.
> 
> yup.  even better (well, conceptually at least), keep your HTML
> document as a tree of elements.  and print it out by walking the tree.
> looks nicely structured when pretty-printed, too.
> 
> [ note: all this is not to say that Guile's string operations are
>   extremely efficient.  but IME most problems that call for fast
>   string operations turn out to be better much solved by different
>   means. ]

I think Michael is right here.  Guile's string operations have been
fast enough for me until now, when used in an appropriate way.  It's
just that people are used to say things like

$foo . "bar"

in Perl or

foo + "bar"

in Java (which is a no--no, btw, use StringBuffer instead).

But if you want to use Strings in a functional way, you cannot avoid
the allocation overhead; that's way I vote for better String
_primitives_ like those in SRFI-13 (and maybe better ones).  Writing
these in C can avoid *a lot* of overhead.

Which reminds me: Have people thought about letting me integrate
SRFI-13 procedures yet?  I am no longer convinced that _all_ of these
procedures are needed, but things like `string-any',
`string-concatenate', `string-join', `string-pad', `string-trim'
etc. seem to be quite useful to me...


Regards,
  'martin



reply via email to

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