simple StringBuilder proposal

[Andreas Leitgeb]

My application, expanding macros for my website ran about 10% faster
when I optimised StringBuilders to use the proper size. I do more
than just concatenate, so the concatenate was actually faster than
that. I forget now the additional speed for the FastCat wrinkle. The
main thing is it does garbage collection less often. It is much
easier to get an accurate fastcat estimate, and the penalty is less
for being off.

I think I missed your point, then. I thought your proposal was merely
to adopt FastCat's varargs-append into standard StringBuilder, but now
it seems you're mainly comparing FastCat's different internal strategy,
instead of just the particular varargs-append().

 

[Jan Burse]

No. But GoF never claimed to be complete.


When Fluent interface is fully used, then it is more than just
cosmetics. It almost becomes a DSL.

I know more or less what you mean. And probably the
pattern also allows returning an object that is different
from "this", to model statechanges etc..

But I guess the "this" variant of the pattern only
solves a problem when the target expression is complex.
So in case I do:

a[x].append(b);
a[x].append(c);

I can replace this by the following, provided a and
x are not volatile:

a[x].append(b)
.append(c);

And I get a little performance improvement, since
a[x] is only fetched once. But again, I could do this
by hand, if the "this" pattern were not implemented:

h = a[x];
h.append(b);
h.append(c);

Bye

 

[Joerg Meier]

Am 27.02.2013 22:51, schrieb Joerg Meier:
Java Compilers will substitute any + operations on String with calls to
StringBuffer (-source 1.3 and below) or StringBuilder (-source 1.4 or
above). I'm not aware, of any optimizations within the JVM (e.g.
Hotspot), but at byte-code level there is no such thing as a + operator
for strings.

I didn't want to lean too far out the window and say "in every situation"
because I was unsure and comments like that just invite someone to post
some weird technicality where one is wrong

Liebe Gruesse,
Joerg

 

[Arne Vajhøj]

I know more or less what you mean. And probably the
pattern also allows returning an object that is different
from "this", to model statechanges etc..

But I guess the "this" variant of the pattern only
solves a problem when the target expression is complex.

True.

String append would not qualify as almost DCl.

Arne

 

[markspace]

I think I missed your point, then. I thought your proposal was merely
to adopt FastCat's varargs-append into standard StringBuilder, but now
it seems you're mainly comparing FastCat's different internal strategy,
instead of just the particular varargs-append().

I think the point of FastCat is its internal strategy. I think the
point of the OP was to point out that StringBuilder might want to adopt
a varargs method.

 

[Jim Janney]

True.

String append would not qualify as almost DCl.

Joda Time is a good example of using fluent interfaces in Java,
especially if you contrast it with the corresponding JDK classes.

http://joda-time.sourceforge.net/

 

[Arne Vajhøj]

Joda Time is a good example of using fluent interfaces in Java,
especially if you contrast it with the corresponding JDK classes.

http://joda-time.sourceforge.net/

And an example that may be more popular than CriteriaBuilder ...



Arne

 

[Robert Klemme]

EnumSet, and there's five of them, not three.

Ah, yes! Thank you for helping my feeble memory, Mark!

It's a rather extreme
case of "let's make this as fast as possible, even to compile directly
to one machine instruction" rather than a general heuristic.

<http://docs.oracle.com/javase/7/docs/api/java/util/EnumSet.html>

Actually I had similar thoughts: EnumSet seemed quite aggressive
optimized. There's also the two bit set implementations underneath
(long and BitSet) which seem to indicate Oracle's engineers expect heavy
use of Enums.

Kind regards

robert

 

[Sven Köhler]

Am 27.02.2013 21:38, schrieb Daniel Pitts:

Now, to be fair to Roedy, you aren't exactly using it "as proscribed",
and you aren't testing the time spent in the constructors.

I've made the Strings you append longer, and I've fixed the estimates
for the FastCat and the StringBu*ers constructors to be spot-on:

Well, in the example Roedy posted here, the strings weren't very long
either.

So, depending on its use, FastCat *can* be about twice as fast as
StringBuffer/StringBuilder.

Which is to be expected as a factor of two is the price to pay or
exponential growth.


Regards,
Sven