Thank you Richard for the detailed response. Noury On Mar 18 2024, at 8:06 am, Richard O'Keefe <raoknz@gmail.com> wrote:
Let me start by giving some figures from my Smalltalk, on an Intel core I5-6200U @ 2.3 Ghz CPU laptop with 8GB of memory running Ubuntu 22.04 and gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0. Smalltalk is compiled to C then finished with the system C compiler. Static whole-program compilation is allowed by the ANSI standard and the system was originally written to serve as a baseline for Bryce's JIT. nsec technique 249 replaceFrom:to:with:startingAt:*5 128 withAll:*5 486 ,,,, 492 (,,),(,) 521 streamContents: 367 StringWriteStream 860 StringBuffer>>addAllLast: 385 StringBuffer>>nextPutAll:
replaceFrom:to:with:startingAt:*5 makes a string the right size then fills it in using #replaceAll:from:to:startingAt:. withAll:*5 is String withAll: a withAll: b withAll: c withAll: d withAll: e (supported up to 6 withAlls.) This is interesting because the result can be a [ReadOnly](ByteArray -- UTF8 -- or ShortArray -- UTF16 or String -- UTF32) and each of the up to 6 operands can independently be these things. It wasn't intended as a fast alternative to #, . .... is a,b,c,d,e (,,),(,) is (a,b,c),(d,e). streamContents: is what you had StringWriteStream is basically the same as streamContents: but using a WriteStream specialised to Strings with some extra primitive support. There are also StringReadStream and StringReadWriteStream. StringBuffer is my version of Java's StringBuilder; it's a cross between a String, an OrderedCollection, and a WriteStream. It can change size like an OrderedCollection; it has most of the "writing" methods (but not the "position" ones) of a WriteStream, and at all times you can use it as a String without having to copy the contents. You would expect #addAllLast: and #nextPutAll: to have the same result, and they do, but they were written a different times and #nextPutAll: was optimised for the case where the operand is a string while #addAllLast: wasn't.
What does all that mean in practice? It means that a benchmark like this is VERY SENSITIVE to the details of how the library is written. Even just bracketing the commas differently gives you a different time.
It means that techniques which are more efficient for LARGE volumes of data may have startup costs that make them less efficient for SMALL volumes of data, and that this is a very small benchmark. The cost of a,b,c,d,e is proportional to |a|*5 + |b|*4 + |c|*3 + |d|*2 + |e|, while the other techniques are proportional to |a| + |b| + |c| + |d| + |e|, BUT have overheads of their own.
Well, that was astc. What about Pharo? 1,950,528 per second' ,,,, 6,509,256 per second' withAll:*5
Here it is. I've added withAll:*2 to withAll:*6 to ArrayedCollection class. withAll: c1 withAll: c2 withAll: c3 withAll: c4 withAll: c5 |e1 e2 e3 e4 e5| e1 := c1 size. e2 := c2 size + e1. e3 := c3 size + e2. e4 := c4 size + e3. e5 := c5 size + e4. ^(self new: e5) replaceFrom: 1 to: e1 with: c1 startingAt: 1; replaceFrom: e1+1 to: e2 with: c2 startingAt: 1; replaceFrom: e2+1 to: e3 with: c3 startingAt: 1; replaceFrom: e3+1 to: e4 with: c4 startingAt: 1; replaceFrom: e4+1 to: e5 with: c5 startingAt: 1; yourself
What's the lesson here? Just because A is faster than B doesn't mean there isn't a fairly obvious C, D, ..., that will beat A.
Now what is the real argument in favour of StringBuilder in Java and streamContents: in Smalltalk?
s := ''. 1 to: n do: [:i | s := s , 'X'].
makes a string of n Xs but takes O(n**2) time and turns over O(n**2) memory. s := String streamContents: [:o | 1 to: n do: [:i | o nextPut: $X] makes a string of n Xs while taking O(n) time and turning over O(n) memory. n does not have to be very big before this gets to be a HUGE difference.
For what it's worth, the Java compiler turns a+b+c+d+e into code that creates a StringBuilder, stuffs a ... e into it, and then pulls a string out. There is no point in benchmarking a fixed number of concatenations against a StringBuilder in Java because they're the same thing. Smalltalk compilers don't do that.
In Java and in Smalltalk you should seldom concatenation strings, but should send the fragments directly to their final destination. I've never quite made up my mind whether being toString()-centric was Java's biggest blunder or just the second biggest, but it was a pretty darned big one for sure. Smalltalk go this right: #printOn: is the basic notion and #printString the derived and best avoided one.
On Sat, 16 Mar 2024 at 08:12, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
I thought streamContents: was faster than using a comma binary message...
I was wrong. Pharo is not Java :-)
Noury
"Run in P11"
a := 'aaaaa'.
b := 'bbbbb'.
c := 'ccccc'.
d := 'ddddd'.
e := 'eeeeee'.
[ a , b , c , d , e ] bench.
"'3958888.090 per second'"
"'3808242.503 per second'"
[
String streamContents: [ :str |
str
<< a;
<< b;
<< c;
<< d;
<< e ] ] bench
"'3083603.838 per second'"
"'2927641.144 per second'" a := 'aaaaa'.
b := 'bbbbb'.
c := 'ccccc'.
d := 'ddddd'.
e := 'eeeeee'.
[ a , b , c , d , e ] bench.
"'3958888.090 per second'"
"'3808242.503 per second'"
[
String streamContents: [ :str |
str
<< a;
<< b;
<< c;
<< d;
<< e ] ] bench
"'3083603.838 per second'"
"'2927641.144 per second'"
a := 'aaaaa'. b := 'bbbbb'. c := 'ccccc'. d := 'ddddd'. e := 'eeeeee'. [ a , b , c , d , e ] bench. "'3958888.090 per second'" "'3808242.503 per second'" [ String streamContents: [ :str | str << a; << b; << c; << d; << e ] ] bench "'3083603.838 per second'" "'2927641.144 per second'"