There may be another downside...

A 1 million times loop of your 2 samples too:

- string concatenation: 9.332 seconds
- TEXTMERGE sequence: 45.210 seconds

I think that the difference makes it worth thinking about before wholeheartedly adopting the TEXTMERGE method.

cheers


>>OK, good points (Al too). It's not just 8k of space, it's 8k x running threaded processes, but I get your point about looking elsewhere to optimize.
>
>One good technique, regarding string composition, is to avoid stuff like
>
>

lcString=" some text here "+lcVariable1+chr(13)
>lcString=lcString+" more text here "+lcVariable2+chr(13)
>lcString=lcString+" yet more text here "+lcVariable3+chr(13)

>
>because it can be done as
>

text textmerge to lcString noshow
>some text here {{lcVariable1}}
>more text here {{lcVariable2}}
>yet more text here {{lcVariable3}}
>endtext

>
>(I've assumed Set Textmerge Delimiters to be {{ and }} so the html parser wouldn't treat them as tags.)
>
>This specially makes sense when you're building a webpage and have a lot of such stuff. The only downside to this is that you can't nest it, i.e. if one of the expandable things is a function call, the function can't do its own textmerge.