[PING Roedy] Re: Optiimising StringBuilder Size revisited

From:

Tom Anderson <twic@urchin.earth.li>

Newsgroups:

comp.lang.java.programmer

Date:

Tue, 23 Sep 2008 17:53:06 +0100

Message-ID:

<Pine.LNX.4.64.0809231751240.17087@urchin.earth.li>

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

---910079544-1547662449-1222188786=:17087
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 22 Sep 2008, Lew wrote:

On Sep 22, 3:32?pm, Tom Anderson <t...@urchin.earth.li> wrote:

On Mon, 22 Sep 2008, Lew wrote:

Tom Anderson wrote:

Indeed, since StringBuffers are generally fairly short-lived, the worry is
not really about using up RAM, it's about generating garbage and making the
collector run more often that it otherwise would. Again, a CPU cost.

Mitigating that, the GC for a young generation with nearly all short-lived
objects is fast. ?The collector is optimized for the use case where nearly
everything dies before a minor collection.

By filling the young generation with dead objects, you incur more frequent GC
cycles that take very little time each. ?Just a copy of the few remaining
live objects in the nursery, and Bob's your uncle.

Discounting the effect of Hotspot on inlining the StringBuilder operations to
where perhaps they have no impact on heap at all.

All well and good.

But when Roedy actually tried it, he made his app run 10% faster.

With the "-server" option to the JVM?

No idea. Roedy?

Not having seen the experiment or the data it used, nor what JVM options
pertained, I don't know how his results generalize to other situations.

True. What would be some good benchmarks for this sort of thing? Javac?
Maybe not. What sort of app builds a lot of strings?

tom

--
Know who said that? Fucking Terrorvision, that's who. -- D
---910079544-1547662449-1222188786=:17087--