Your second definition is “newContent = (pageContent page) . (str ++)”, which is better for the reasons that Eugene Kirpichov notes.

By the way, in Haskell string concatenation is less of a performance hog because of its laziness: for example, completely evaluating s1 ++ s2 will only take as much time and memory as needed to scan s1 and then scan s2.

Consider the implementation of (++):

[] ++ bs = bs
(a:as) ++ bs = a:(as++bs)

So, to know the next element of (as++bs), you have to check whether ‘as’ is empty.

However, for ((s1 ++ s2) ++ s3) ++ s4, to know its very first element, you have to check whether (s1++s2)++s3 is empty, for that you have to check whether (s1++s2) is empty, and for that you have to check whether s1 is empty. And these 4 operations continue to happen until s1 ends; after that you have 3 operations until s2 ends etc.

So, fully evaluating the contatenation of N strings of lengths L1,L2,..,LN in a *LEFT*-fold fashion takes N*L1 + (N-1)*L2 + … steps.

Note that if you concatenate from the *RIGHT*, you will have absolutely no problems: completely evaluating s1 ++ (s2 ++ (s3 ++ s4)) takes only as much time as needed to scan s1, then scan s2, then s3, then s4.

“”.join(strings)

in Python code, for example?