Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #22526 > unrolled thread

simple StringBuilder proposal

Back to article view | Back to comp.lang.java.programmer

Contents

  simple StringBuilder proposal Roedy Green <see_website@mindprod.com.invalid> - 2013-02-26 03:53 -0800
    Re: simple StringBuilder proposal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-02-26 15:15 +0000
      Re: simple StringBuilder proposal Roedy Green <see_website@mindprod.com.invalid> - 2013-02-27 10:25 -0800
      Re: simple StringBuilder proposal Roedy Green <see_website@mindprod.com.invalid> - 2013-02-27 10:30 -0800
        Re: simple StringBuilder proposal Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-02-28 08:30 +0000
          Re: simple StringBuilder proposal markspace <markspace@nospam.nospam> - 2013-02-28 07:54 -0800
    Re: simple StringBuilder proposal markspace <markspace@nospam.nospam> - 2013-02-26 08:31 -0800
      Re: simple StringBuilder proposal Lew <lewbloch@gmail.com> - 2013-02-26 10:33 -0800
        Re: simple StringBuilder proposal markspace <markspace@nospam.nospam> - 2013-02-26 10:47 -0800
          Re: simple StringBuilder proposal Leif Roar Moldskred <leifm@dimnakorr.com> - 2013-02-26 13:29 -0600
            Re: simple StringBuilder proposal Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-26 12:08 -0800
          Re: simple StringBuilder proposal Lew <lewbloch@gmail.com> - 2013-02-26 13:32 -0800
            Re: simple StringBuilder proposal Roedy Green <see_website@mindprod.com.invalid> - 2013-02-27 10:33 -0800
          Re: simple StringBuilder proposal Robert Klemme <shortcutter@googlemail.com> - 2013-02-26 22:53 +0100
            Re: simple StringBuilder proposal markspace <markspace@nospam.nospam> - 2013-02-26 15:54 -0800
              Re: simple StringBuilder proposal Robert Klemme <shortcutter@googlemail.com> - 2013-03-01 07:35 +0100
        Re: simple StringBuilder proposal Roedy Green <see_website@mindprod.com.invalid> - 2013-02-27 10:31 -0800
          Re: simple StringBuilder proposal Sven Köhler <remove-sven.koehler@gmail.com> - 2013-02-28 05:14 +0100
    Re: simple StringBuilder proposal Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-26 09:41 -0800
    Re: simple StringBuilder proposal Jan Burse <janburse@fastmail.fm> - 2013-02-26 20:21 +0100
      Re: simple StringBuilder proposal Joerg Meier <joergmmeier@arcor.de> - 2013-02-26 23:07 +0100
        Re: simple StringBuilder proposal Jan Burse <janburse@fastmail.fm> - 2013-02-27 00:09 +0100
          Re: simple StringBuilder proposal Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-26 15:19 -0800
            Re: simple StringBuilder proposal Jim Janney <jjanney@shell.xmission.com> - 2013-02-27 09:34 -0700
              Re: simple StringBuilder proposal Jan Burse <janburse@fastmail.fm> - 2013-02-27 19:18 +0100
                Re: simple StringBuilder proposal Arne Vajhøj <arne@vajhoej.dk> - 2013-02-27 19:56 -0500
                  Re: simple StringBuilder proposal Jan Burse <janburse@fastmail.fm> - 2013-02-28 10:19 +0100
                    Re: simple StringBuilder proposal Arne Vajhøj <arne@vajhoej.dk> - 2013-02-28 08:16 -0500
                      Re: simple StringBuilder proposal Jim Janney <jjanney@shell.xmission.com> - 2013-02-28 16:40 -0700
                        Re: simple StringBuilder proposal Arne Vajhøj <arne@vajhoej.dk> - 2013-02-28 18:51 -0500
              Re: simple StringBuilder proposal Arne Vajhøj <arne@vajhoej.dk> - 2013-02-27 20:01 -0500
    Re: simple StringBuilder proposal Silvio <silvio@internet.com> - 2013-02-26 22:03 +0100
      Re: simple StringBuilder proposal Silvio <silvio@internet.com> - 2013-02-26 22:04 +0100
    Re: simple StringBuilder proposal Sven Köhler <remove-sven.koehler@gmail.com> - 2013-02-27 03:47 +0100
      FastCat 'performance' (was: simple StringBuilder proposal) Joerg Meier <joergmmeier@arcor.de> - 2013-02-27 18:16 +0100
        Re: FastCat 'performance' markspace <markspace@nospam.nospam> - 2013-02-27 09:58 -0800
          Re: FastCat 'performance' Jan Burse <janburse@fastmail.fm> - 2013-02-27 19:31 +0100
            Re: FastCat 'performance' Joerg Meier <joergmmeier@arcor.de> - 2013-02-27 20:00 +0100
              Re: FastCat 'performance' Jan Burse <janburse@fastmail.fm> - 2013-02-27 20:41 +0100
                Re: FastCat 'performance' Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-27 12:38 -0800
                  Re: FastCat 'performance' Joerg Meier <joergmmeier@arcor.de> - 2013-02-27 21:58 +0100
                    Re: FastCat 'performance' Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-27 13:32 -0800
                  Re: FastCat 'performance' Lew <lewbloch@gmail.com> - 2013-02-27 13:42 -0800
                    Re: FastCat 'performance' Lew <lewbloch@gmail.com> - 2013-02-27 13:44 -0800
                    Re: FastCat 'performance' Joerg Meier <joergmmeier@arcor.de> - 2013-02-27 22:51 +0100
                      Re: FastCat 'performance' Sven Köhler <remove-sven.koehler@gmail.com> - 2013-02-28 05:19 +0100
                        Re: FastCat 'performance' Joerg Meier <joergmmeier@arcor.de> - 2013-02-28 13:09 +0100
                  Re: FastCat 'performance' markspace <markspace@nospam.nospam> - 2013-02-27 13:57 -0800
                    Re: FastCat 'performance' Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-27 15:23 -0800
                  Re: FastCat 'performance' Arne Vajhøj <arne@vajhoej.dk> - 2013-02-27 18:52 -0500
                  Re: FastCat 'performance' Sven Köhler <remove-sven.koehler@gmail.com> - 2013-03-01 17:26 +0100
        Re: FastCat 'performance' Sven Köhler <remove-sven.koehler@gmail.com> - 2013-02-27 21:00 +0100
        Re: FastCat 'performance' (was: simple StringBuilder proposal) Wanja Gayk <brixomatic@yahoo.com> - 2013-03-27 10:17 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#22556

On Tue, 26 Feb 2013 20:21:58 +0100, Jan Burse wrote:

> Since append() returns the StringBuilder itself, you can also write:

> sb.append("<input name=\"cx\" type=\"hidden\" value=\"")
>    .append(cseAccount)
>    .append(":")
>    .append(cseCode)
>    .append("\">\n");

> There are a couple of methods in the JDK that are designed this way.

@Accessors (chain = true) from the wonderful Lombok does that too, and I
think it's a great pattern for certain cases such as classes with a lot of
fields with sensible defaults, where one usually only wants to change one
or two out of a dozen (but usually different ones).

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#22557

Joerg Meier schrieb:
> On Tue, 26 Feb 2013 20:21:58 +0100, Jan Burse wrote:
>
>> Since append() returns the StringBuilder itself, you can also write:
>
>> sb.append("<input name=\"cx\" type=\"hidden\" value=\"")
>>     .append(cseAccount)
>>     .append(":")
>>     .append(cseCode)
>>     .append("\">\n");
>
>> There are a couple of methods in the JDK that are designed this way.
>
> @Accessors (chain = true) from the wonderful Lombok does that too, and I
> think it's a great pattern for certain cases such as classes with a lot of
> fields with sensible defaults, where one usually only wants to change one
> or two out of a dozen (but usually different ones).
>
> Liebe Gruesse,
> 		Joerg
>


Do you mean the google builder pattern? It makes also use of it:

http://www.javacodegeeks.com/2012/07/builder-design-pattern-in-java.html

Bye

[toc] | [prev] | [next] | [standalone]

#22558

On 2/26/13 3:09 PM, Jan Burse wrote:
> Joerg Meier schrieb:
>> On Tue, 26 Feb 2013 20:21:58 +0100, Jan Burse wrote:
>>
>>> Since append() returns the StringBuilder itself, you can also write:
>>
>>> sb.append("<input name=\"cx\" type=\"hidden\" value=\"")
>>>     .append(cseAccount)
>>>     .append(":")
>>>     .append(cseCode)
>>>     .append("\">\n");
>>
>>> There are a couple of methods in the JDK that are designed this way.
>>
>> @Accessors (chain = true) from the wonderful Lombok does that too, and I
>> think it's a great pattern for certain cases such as classes with a
>> lot of
>> fields with sensible defaults, where one usually only wants to change one
>> or two out of a dozen (but usually different ones).
>>
>> Liebe Gruesse,
>>         Joerg
>>
>
>
> Do you mean the google builder pattern? It makes also use of it:
>
> http://www.javacodegeeks.com/2012/07/builder-design-pattern-in-java.html

The pattern of a "Builder" is older than Google. So is chaining. Both 
are useful techniques if applied appropriately. As with any pattern, 
don't create a problem that is solved by your pattern, but know lots of 
patterns and apply the right pattern to solve your specific problem.

[toc] | [prev] | [next] | [standalone]

#22576

Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:

> On 2/26/13 3:09 PM, Jan Burse wrote:
>>
>> Do you mean the google builder pattern? It makes also use of it:
>>
>> http://www.javacodegeeks.com/2012/07/builder-design-pattern-in-java.html
>
> The pattern of a "Builder" is older than Google. So is chaining. Both
> are useful techniques if applied appropriately. As with any pattern,
> don't create a problem that is solved by your pattern, but know lots
> of patterns and apply the right pattern to solve your specific
> problem.

The general approach is sometimes called a fluent interface.

    http://www.martinfowler.com/bliki/FluentInterface.html

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#22580

Jim Janney schrieb:
> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>
>> On 2/26/13 3:09 PM, Jan Burse wrote:
>>>
>>> Do you mean the google builder pattern? It makes also use of it:
>>>
>>> http://www.javacodegeeks.com/2012/07/builder-design-pattern-in-java.html
>>
>> The pattern of a "Builder" is older than Google. So is chaining. Both
>> are useful techniques if applied appropriately. As with any pattern,
>> don't create a problem that is solved by your pattern, but know lots
>> of patterns and apply the right pattern to solve your specific
>> problem.
>
> The general approach is sometimes called a fluent interface.
>
>      http://www.martinfowler.com/bliki/FluentInterface.html
>

So its not in the GoF book? But the "pattern" rather feels
to me like a micro pattern, and not a full fledged pattern.
Since it doesn't realy solve a problem, its just cosmetics.

Bye

[toc] | [prev] | [next] | [standalone]

#22604

On 2/27/2013 1:18 PM, Jan Burse wrote:
> Jim Janney schrieb:
>> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>>
>>> On 2/26/13 3:09 PM, Jan Burse wrote:
>>>>
>>>> Do you mean the google builder pattern? It makes also use of it:
>>>>
>>>> http://www.javacodegeeks.com/2012/07/builder-design-pattern-in-java.html
>>>>
>>>
>>> The pattern of a "Builder" is older than Google. So is chaining. Both
>>> are useful techniques if applied appropriately. As with any pattern,
>>> don't create a problem that is solved by your pattern, but know lots
>>> of patterns and apply the right pattern to solve your specific
>>> problem.
>>
>> The general approach is sometimes called a fluent interface.
>>
>>      http://www.martinfowler.com/bliki/FluentInterface.html
>
> So its not in the GoF book?

No. But GoF never claimed to be complete.

>                             But the "pattern" rather feels
> to me like a micro pattern, and not a full fledged pattern.
> Since it doesn't realy solve a problem, its just cosmetics.

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

Arne

[toc] | [prev] | [next] | [standalone]

#22613

Arne Vajhøj schrieb:
> No. But GoF never claimed to be complete.
>
>>                             But the "pattern" rather feels
>> to me like a micro pattern, and not a full fledged pattern.
>> Since it doesn't realy solve a problem, its just cosmetics.
>
> 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

[toc] | [prev] | [next] | [standalone]

#22615

On 2/28/2013 4:19 AM, Jan Burse wrote:
> Arne Vajhøj schrieb:
>> No. But GoF never claimed to be complete.
>>
>>>                             But the "pattern" rather feels
>>> to me like a micro pattern, and not a full fledged pattern.
>>> Since it doesn't realy solve a problem, its just cosmetics.
>>
>> 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.

True.

String append would not qualify as almost DCl.

Arne

[toc] | [prev] | [next] | [standalone]

#22640

Arne Vajhøj <arne@vajhoej.dk> writes:

> On 2/28/2013 4:19 AM, Jan Burse wrote:
>> Arne Vajhøj schrieb:
>>> No. But GoF never claimed to be complete.
>>>
>>>>                             But the "pattern" rather feels
>>>> to me like a micro pattern, and not a full fledged pattern.
>>>> Since it doesn't realy solve a problem, its just cosmetics.
>>>
>>> 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.
>
> 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/

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#22641

On 2/28/2013 6:40 PM, Jim Janney wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>
>> On 2/28/2013 4:19 AM, Jan Burse wrote:
>>> Arne Vajhøj schrieb:
>>>> No. But GoF never claimed to be complete.
>>>>
>>>>>                              But the "pattern" rather feels
>>>>> to me like a micro pattern, and not a full fledged pattern.
>>>>> Since it doesn't realy solve a problem, its just cosmetics.
>>>>
>>>> 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.
>>
>> 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/

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

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#22605

On 2/27/2013 11:34 AM, Jim Janney wrote:
> Daniel Pitts <newsgroup.nospam@virtualinfinity.net> writes:
>
>> On 2/26/13 3:09 PM, Jan Burse wrote:
>>>
>>> Do you mean the google builder pattern? It makes also use of it:
>>>
>>> http://www.javacodegeeks.com/2012/07/builder-design-pattern-in-java.html
>>
>> The pattern of a "Builder" is older than Google. So is chaining. Both
>> are useful techniques if applied appropriately. As with any pattern,
>> don't create a problem that is solved by your pattern, but know lots
>> of patterns and apply the right pattern to solve your specific
>> problem.
>
> The general approach is sometimes called a fluent interface.
>
>      http://www.martinfowler.com/bliki/FluentInterface.html

They are extremely popular in the .NET world.

But they are also found in the Java world. They seem to
be popular in ORM's (well - popular with the ORM API
creators - I suspect that the ORM API users may be
less happy).

Arne

[toc] | [prev] | [next] | [standalone]

#22552

On 02/26/2013 12:53 PM, Roedy Green wrote:
>
> With FastCat, I can write:
>
>   sb.append( "<input name=\"cx\" type=\"hidden\" value=\"", cseAccount,
> ":", cseCode, "\">\n" );
>
> It is just shorthand for
>
> sb.append( "<input name=\"cx\" type=\"hidden\" value=\"",)
> sb.append(cseAccount);
> sb.append(":");
> sb.append(cseCode);
> sb.append( "\">\n" );
>
> I propose StringBuilder learn the same trick.
>

Ask the Java8 crew to implement something more generally useful that 
would allow you to define this for yourself. Google for "pimp my library 
in Scala".

Scala allows adding methods to existing classes by means of what are 
called implicit conversions. Using structural typing you could even 
define an implicit conversion for everything with an append(String) 
method to support an append(Any*). This would involve only compiler 
magic without an actual wrapper object.

[toc] | [prev] | [next] | [standalone]

#22553

On 02/26/2013 10:03 PM, Silvio wrote:
> On 02/26/2013 12:53 PM, Roedy Green wrote:
>>
>> With FastCat, I can write:
>>
>>   sb.append( "<input name=\"cx\" type=\"hidden\" value=\"", cseAccount,
>> ":", cseCode, "\">\n" );
>>
>> It is just shorthand for
>>
>> sb.append( "<input name=\"cx\" type=\"hidden\" value=\"",)
>> sb.append(cseAccount);
>> sb.append(":");
>> sb.append(cseCode);
>> sb.append( "\">\n" );
>>
>> I propose StringBuilder learn the same trick.
>>
>
> Ask the Java8 crew to implement something more generally useful that
> would allow you to define this for yourself. Google for "pimp my library
> in Scala".
>
> Scala allows adding methods to existing classes by means of what are
> called implicit conversions. Using structural typing you could even
> define an implicit conversion for everything with an append(String)
> method to support an append(Any*). This would involve only compiler
> magic without an actual wrapper object.

Oops, too late. Make that Java9.

[toc] | [prev] | [next] | [standalone]

#22562

Hi,

Am 26.02.2013 12:53, schrieb Roedy Green:
> With FastCat, I can write:
> 
>  sb.append( "<input name=\"cx\" type=\"hidden\" value=\"", cseAccount,
> ":", cseCode, "\">\n" );

So I googled and found a FastCat class that has append(String ...) and
append(Object ...) methods. And just by coincidence, you're a co-author
of that class.

So basically, whatever arguments you pass, they are first wrapped in an
array, and then passed to the append method. To make things worse, if
you'd pass a mix of char, int, double, etc. - some of these things would
first be wrapped in Char, Integer, Double, etc. - and then the
toString() method is called.

> It is just shorthand for
> 
> sb.append( "<input name=\"cx\" type=\"hidden\" value=\"",)
> sb.append(cseAccount);
> sb.append(":");
> sb.append(cseCode);
> sb.append( "\">\n" );

No it is not.

> I propose StringBuilder learn the same trick.

So, are you aware of the performance hit? Are you trying to say, that
you prefer convenience over performance here? And if you don't care
about performance in this particular case, why don't you use the +
operator for Strings which is pretty convenient? Or why don't you
exploit the fact that append() returns the StringBuilder instance?

I'm not sure, what to make of your posting. Are you just trying to
promote the FastCat class?

Would you happen to have a benchmark, where you append lots of integers
to a FastCat and a StringBuilder? I would love to see what happens if
you use the append(Object...) method for that.


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#22578 — FastCat 'performance' (was: simple StringBuilder proposal)

On Wed, 27 Feb 2013 03:47:24 +0100, Sven Köhler wrote:

> Am 26.02.2013 12:53, schrieb Roedy Green:
>> With FastCat, I can write:

>>  sb.append( "<input name=\"cx\" type=\"hidden\" value=\"", cseAccount,
>> ":", cseCode, "\">\n" );
> So I googled and found a FastCat class that has append(String ...) and
> append(Object ...) methods. And just by coincidence, you're a co-author
> of that class.

Shocking, Roedy advertising for himself.

> So, are you aware of the performance hit? Are you trying to say, that
> you prefer convenience over performance here? And if you don't care
> about performance in this particular case, why don't you use the +
> operator for Strings which is pretty convenient? Or why don't you
> exploit the fact that append() returns the StringBuilder instance?

> I'm not sure, what to make of your posting. Are you just trying to
> promote the FastCat class?

> Would you happen to have a benchmark, where you append lots of integers
> to a FastCat and a StringBuilder? I would love to see what happens if
> you use the append(Object...) method for that.

Because his incessant advertising irritates me, I spent a few minutes
writing a small benchmark, comparing the performance of StringBuilder,
StringBuffer and FastCat. The results were ... well, pretty much what one
would expect:

Took 00:08.845ms to append 454,895,082 chars total with FastCat.
Took 00:03.939ms to append 454,895,082 chars total with StringBuffer.
Took 00:03.462ms to append 454,895,082 chars total with StringBuilder.

So FastCat is about 2.3 times slower than the Oracle/Sun implementation of
StringBuffer, and 2.6 times slower than the unsychronized StringBuilder.
Shocker.

Not wanting to be too harsh on Roedy, seeing as how he's probably freed
Europe during WWII, I figured I'd run the benchmark again, but instead of
instantiating millions of StringB*S/FastCatS, I'd reuse the same one.
Maybe, after all, it was the object creation that caused the difference.

Hilariously, at this point, I started getting exceptions thrown into my
face - FastCat doesn't support fancy things like appending more than 1000
chars or so. And instead of signalling that with a proper error code, it
abuses ArrayIndexOutOfBoundsException to signal that it ... refuses to
resize itself ?

Don't get me wrong, it's not a bug causing that, he actually explicitly
throws that exception when his buffer gets full, outright refusing to
resize the object. Because terminating with an exception is better for
performance ... right ?

/**
 * We overflowed the array.  Give up.  Get user to improve estimate.  We
could recover automatically,
 * but that would defeat the intent of fast code.
 */
 
Couldn't make this up if I tried. I decided to FastCat's metaphorical arm
over my shoulder and just told it to make more buffer space in the
constructor, and this is the glorious outcome of reusing the same SB/FC
object:

Took 00:14.763ms to append 454,895,082 chars total with FastCat.
Took 00:03.384ms to append 454,895,082 chars total with StringBuffer.
Took 00:02.825ms to append 454,895,082 chars total with StringBuilder.

At this point, I vote that Roedy has to rename it to SlowCat.

Test code (ugly, but too lazy to clean it up):

<http://pastebin.com/TNj7Fmqy>

Note that you need plenty of RAM if you want to keep all those bytes in
memory. I used -Xmx4G -Xms4G, though you can probably make due with less.

ps.: When I just went to post the code, I noticed that by accident I didn't
actually *USE* Roedys advanced syntax. Instead, as with the SB classes, I
used multiple .append()s. Talk about embarassing, luckily I noticed before
I pressed send.

I was about ready to delete this whole post, thanking the good spirits of
Usenet for saving me from the shame of publically embarassing myself when
it turned out that a small change to his advanced syntax would speed
FastCat up by leaps and bounds.

No. In fact, his advanced syntax is *EVEN* *SLOWER*: 6.4 times slower than
StringBuilder, to be exact.

Took 00:18.016ms to append 454,895,082 chars total with FastCat.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#22579 — Re: FastCat 'performance'

On 2/27/2013 9:16 AM, Joerg Meier wrote:

> No. In fact, his advanced syntax is *EVEN* *SLOWER*: 6.4 times slower than
> StringBuilder, to be exact.

But only 22% slower than FastCat#append, which suggests to me that 
varargs are acceptable where performance is not an issue, and 
convenience is.

(Although, FastCat's slow performance might be masking the the true 
overhead of varargs.  But it doesn't seem to me to be fair to call 
varargs a 640% slowdown by itself.)

Good job actually sussing this out.  You did far more work with a 
questionable library than I was willing to.

[toc] | [prev] | [next] | [standalone]

#22584 — Re: FastCat 'performance'

markspace schrieb:
> Good job actually sussing this out.  You did far more work with a
> questionable library than I was willing to.

Well it would be of interest to see the test
programs for all the different classes. FastCat
has definitively a problem here:

        return new String( buffer );  // Would like
                   // some way to just hand buffer over to
                   // String to avoid copy.


 
https://wush.net/websvn/mindprod/filedetails.php?repname=mindprod&path=%2Fcom%2Fmindprod%2Ffastcat%2FFastCat.java

But it also depends what the other test programs
do, and whether the result is really comparable. Does
the test program for StringBuilder call toString()?

I guess without calling toString() the test programs
are not comparable, since the use case would differ.

Bye
Bye

[toc] | [prev] | [next] | [standalone]

#22586 — Re: FastCat 'performance'

On Wed, 27 Feb 2013 19:31:43 +0100, Jan Burse wrote:

> markspace schrieb:
>> Good job actually sussing this out.  You did far more work with a
>> questionable library than I was willing to.
> Well it would be of interest to see the test
> programs for all the different classes. FastCat
> has definitively a problem here:

I posted a link to the full test program upthread.

> But it also depends what the other test programs
> do, and whether the result is really comparable. Does
> the test program for StringBuilder call toString()?

> I guess without calling toString() the test programs
> are not comparable, since the use case would differ.

I did not, but a change of the lines to:

return sbLocal.toString().length() - start;

changed the performance like so (with the reusing ones running loops/250):

Fresh SB/FCs:
Took 00:10.927ms to append 454,895,082 chars total with FastCat.
Took 00:03.980ms to append 454,895,082 chars total with StringBuffer.
Took 00:03.678ms to append 454,895,082 chars total with StringBuilder.
Reused SB/FCs:
Took 02:51.926ms to append 1,623,732 chars total with FastCat.
Took 00:13.920ms to append 1,623,732 chars total with StringBuffer.
Took 00:13.987ms to append 1,623,732 chars total with StringBuilder

So, FastCat is doing even worse if .toString() is used. And much, much
worse if .toString() is used more than once.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#22587 — Re: FastCat 'performance'

Joerg Meier schrieb:
> So, FastCat is doing even worse if .toString() is used. And much, much
> worse if .toString() is used more than once.
>
> Liebe Gruesse,
> 		Joerg

Ok, so then. Thanks.

[toc] | [prev] | [next] | [standalone]

#22592 — Re: FastCat 'performance'

On 2/27/13 11:41 AM, Jan Burse wrote:
> Joerg Meier schrieb:
>> So, FastCat is doing even worse if .toString() is used. And much, much
>> worse if .toString() is used more than once.
>>
>> Liebe Gruesse,
>>         Joerg
>
> Ok, so then. Thanks.
>
>
>
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:

Fresh SB/FCs:
Cat> Init: 00.000ms, Loop: 00.175ms, End: 00.000ms, Total: 00.175ms.
Buf> Init: 00.000ms, Loop: 00.227ms, End: 00.000ms, Total: 00.227ms.
Bui> Init: 00.000ms, Loop: 00.236ms, End: 00.000ms, Total: 00.236ms.
Reused SB/FCs:
Cat> Init: 00.000ms, Loop: 00.023ms, End: 00.375ms, Total: 00.398ms.
Buf> Init: 00.101ms, Loop: 00.048ms, End: 00.130ms, Total: 00.279ms.
Bui> Init: 00.092ms, Loop: 00.052ms, End: 00.130ms, Total: 00.274ms.


For Fresh, Init/End do nothing, but toString() is called every loop.

For Reused, Init creates the buffer/builder/fastcat,  and End is the 
single call to toString().

If I remove the estimate entirely from StringBu*er constructors, FastCat 
does indeed win out. FastCat relies on a "good estimate" to start with, 
so I left that estimate in.

Fresh SB/FCs:
Cat> Init: 00.000ms, Loop: 00.187ms, End: 00.000ms, Total: 00.187ms.
Buf> Init: 00.000ms, Loop: 00.240ms, End: 00.000ms, Total: 00.240ms.
Bui> Init: 00.000ms, Loop: 00.236ms, End: 00.000ms, Total: 00.236ms.
Reused SB/FCs:
Cat> Init: 00.000ms, Loop: 00.020ms, End: 00.377ms, Total: 00.397ms.
Buf> Init: 00.000ms, Loop: 00.495ms, End: 00.122ms, Total: 00.617ms.
Bui> Init: 00.000ms, Loop: 00.468ms, End: 00.121ms, Total: 00.589ms.


So, depending on its use, FastCat *can* be about twice as fast as 
StringBuffer/StringBuilder.  It can, however, be significantly slower as 
you have shown.

Sorry Roedy, I'm not going to switch to FastCat any time soon.  It's not 
a bad idea for a specialized use-case, but as a general use-case not as 
good.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web