[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: string vs list processing
From: |
Martin Grabmueller |
Subject: |
Re: string vs list processing |
Date: |
Wed, 18 Apr 2001 06:36:17 +0200 |
> From: "Jorgen 'forcer' Schaefer" <address@hidden>
> Date: 17 Apr 2001 22:55:27 +0200
>
> Martin Grabmueller <address@hidden> writes:
>
> > If you want that to be fast, check out my SRFI-13 (string
> > library) implementation, where a call to
> > `reverse-string-concatenate' only costs you two traversals over
> > the list, one malloc() and one memcpy() of each element string.
> > I think this is as fast as you can get.
>
> You could spare one of the traversals if you'd record the length
> of the total string while building up the list. If you already
> know you're going to concatenate the whole thing, this might be a
> very worthwhile thing to do.
[...]
Of course, what I actually meant was: `...as fast as you can get
without using a specialized datatype (tree, cord, whatever)'.
Regards,
'martin
- Re: SRFI-13 again [was: Re: string vs list processing], (continued)
- Re: SRFI-13 again [was: Re: string vs list processing], Rob Browning, 2001/04/20
- Re: SRFI-13 again [was: Re: string vs list processing], Per Bothner, 2001/04/19
- Re: SRFI-13 again [was: Re: string vs list processing], Martin Grabmueller, 2001/04/19
- Re: SRFI-13 again [was: Re: string vs list processing], Per Bothner, 2001/04/19
- Re: string vs list processing, Martin Grabmueller, 2001/04/17
- Re: string vs list processing, Jorgen 'forcer' Schaefer, 2001/04/17
- Re: string vs list processing,
Martin Grabmueller <=
- Re: string vs list processing, Neil Jerram, 2001/04/17
- Re: string vs list processing, Marius Vollmer, 2001/04/16