You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2002/11/11 14:43:19 UTC
DO NOT REPLY [Bug 14444] -
[PATCH] a performance patch for PDFInfo class
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14444>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14444
[PATCH] a performance patch for PDFInfo class
------- Additional Comments From jeremias.maerki@outline.ch 2002-11-11 13:43 -------
Please check that diff again. It seems to have a bug:
StringBuffer buf = new StrinfgBuffer();
Please run the compiler and test before submitting the patch. But yes, this
kind of patch is interesting for us, especially because it's for the redesign.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A performance patch for PDFInfo class
Posted by Jeremias Maerki <de...@greenmail.ch>.
Hey, thanks Kevin, for going through the pains of explaining this. I
almost new when I wrote the reply that you might come with this. Anyway,
I didn't know about these compiler optimizations. I've read an article
on Java optimization more about 18 months ago, where the
StringBufferChained approach was favored. Probably, in the meantime the
compiler was improved. I think you're right on target with your analysis.
On 11.11.2002 22:46:36 Kevin O'Neill wrote:
> Sorry if this seems hard but this is the sort of performance enhancement
> I was talking about yesterday. If people are going to do these sorts of
> "enhancements" then they should be aware of the effects.
<snip/>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A performance patch for PDFInfo class
Posted by "Peter B. West" <pb...@powerup.com.au>.
Kevin O'Neill wrote:
> On Tue, 2002-11-12 at 11:21, Peter B. West wrote:
>
>>"I like it" is the acid test; for me, of all code, but in particular for
>>open source. Open source may be driven by many things, but money is not
>>one of them. Pleasure is, and is high on the list. In spite of that,
>>OS generates vast amounts of high-quality software. Go figure.
>
>
> I'll disagree, open source can be driven by money, but lets agree to
> disagree :). We both agree that OS rocks though.
Yes, I take your point, and I am happy that companies are beginning to
invest significant resources in OS. I just hope the the primary
impulses of OS are not suppressed in the process.
How unusual it is to have an (almost) shared time zone.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A performance patch for PDFInfo class
Posted by Kevin O'Neill <ke...@rocketred.com.au>.
On Tue, 2002-11-12 at 11:21, Peter B. West wrote:
> Kevin O'Neill wrote:
> > <snip/>
> >
> >>>So the first recommendation is to use String "+" for this type of
> >>>method, it's easier to read and runs faster.
> >>
>
> >> [This is from Arved.]
>
> >>This kind of thing is discussed by Jack Shirazi at length, also.
> >>
> >>The thing is, there has long been a blanket instruction, don't use String
> >>concatenation. Programmers learn it by fiat, and never think it through. In
> >>fact, it should be obvious to any programmer (if they are encouraged to
> >>think, that is) that concatenation of literal Strings is not something to
> >>avoid. Assuming a decent compiler.
> >
> >
> > You've hit the nail on the head. Optimizations are just that
> > optimizations. They are not "blanket application" things.
>
> Which of course applies to methodological, or "style", optimisations as
> well. Yes, programmers learn by fiat, and yes, they rarely think it
> through. For example: always use the interface, not the implementation.
> Never do early optimisation.
No rule is concrete, I don't think I ever say never :), but having
guidelines that say things like: "For published methods it's preferable
to return an interface instance as opposed to a concrete class as it
allows you to change the internals of the class without breaking
external contracts. In short it improves encapsulation", helps a
developer make choices.
> > Like anybody else there are times when I optimize as I go, but I really
> > try and keep in mind, "is this the simplest thing I could do?" Fighting
> > the urge to apply "optimizations" as you go is hard sometimes but in my
> > experience leads to a better code base.
>
> I almost always surrender to this urge immediately. As with most urges
> to which I surrender, I often I regret it afterwards, although nowhere
> near as frequently as with some of the other urges to which I have been
> known to surrender.
:)
> Despite my occasional regrets, and my occasional unwinding of
> optimisations which did not work, I know with complete certainty that I
> expend hugely less energy on my optimisation regrets (which after all
> represent a minority of cases) than I would if I agonised over every
> temptation. At the end of the day, I am not ashamed of the code I have
> written over the years, even though, naturally, I would do much of it
> differently now.
>
> > When you do apply an optimization, prove it's worth. Create a small set
> > of tests that show the difference and try and run them on a number of
> > vms.
> >
> > You'd be surprised at the things I've found, on one embedded vm
> >
> > x = (y == null) ? a : b;
> >
> > was 50% slower than
> >
> > if (y == null)
> > x = a;
> > else
> > x = b;
> >
> > go figure.
>
> Indeed. I would never dream of writing such a test.
> x = (y == null) ? a : b;
> is quicker to write than the other, and I like it. Such a difference in
> performance is highly dependent on the particular compiler
> implementation, and is subject to radical unannounced variation. I
> would just write it and get on.
Neither did I until a series of code blocks containing the operator came
up in the performance tests. The code was compiled with the JDK 1.3.1
for 1.1 compatibility. I'm in no way suggesting not using the operator.
It was an example of where you can sometime find performance differences
and is a classic example of something that is likely to change with each
release of the jvm/compiler (jdk 1.4.1 does produce slightly different
opcodes) and something you should NOT optimize out except in extreme
circumstances. I love a = b < 1 ? -1 : 1. (oh we did optimize this out,
it was in the main paint loop as gave us a 2% overall speed
improvement).
> "I like it" is the acid test; for me, of all code, but in particular for
> open source. Open source may be driven by many things, but money is not
> one of them. Pleasure is, and is high on the list. In spite of that,
> OS generates vast amounts of high-quality software. Go figure.
I'll disagree, open source can be driven by money, but lets agree to
disagree :). We both agree that OS rocks though.
> Peter
> --
> Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
> "Lord, to whom shall we go?"
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
--
If you don't test then your code is only a collection of bugs which
apparently behave like a working program.
Website: http://www.rocketred.com.au/blogs/kevin/
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A performance patch for PDFInfo class
Posted by "Peter B. West" <pb...@powerup.com.au>.
Kevin O'Neill wrote:
> <snip/>
>
>>>So the first recommendation is to use String "+" for this type of
>>>method, it's easier to read and runs faster.
>>
>> [This is from Arved.]
>>This kind of thing is discussed by Jack Shirazi at length, also.
>>
>>The thing is, there has long been a blanket instruction, don't use String
>>concatenation. Programmers learn it by fiat, and never think it through. In
>>fact, it should be obvious to any programmer (if they are encouraged to
>>think, that is) that concatenation of literal Strings is not something to
>>avoid. Assuming a decent compiler.
>
>
> You've hit the nail on the head. Optimizations are just that
> optimizations. They are not "blanket application" things.
Which of course applies to methodological, or "style", optimisations as
well. Yes, programmers learn by fiat, and yes, they rarely think it
through. For example: always use the interface, not the implementation.
Never do early optimisation.
> Like anybody else there are times when I optimize as I go, but I really
> try and keep in mind, "is this the simplest thing I could do?" Fighting
> the urge to apply "optimizations" as you go is hard sometimes but in my
> experience leads to a better code base.
I almost always surrender to this urge immediately. As with most urges
to which I surrender, I often I regret it afterwards, although nowhere
near as frequently as with some of the other urges to which I have been
known to surrender.
Despite my occasional regrets, and my occasional unwinding of
optimisations which did not work, I know with complete certainty that I
expend hugely less energy on my optimisation regrets (which after all
represent a minority of cases) than I would if I agonised over every
temptation. At the end of the day, I am not ashamed of the code I have
written over the years, even though, naturally, I would do much of it
differently now.
> When you do apply an optimization, prove it's worth. Create a small set
> of tests that show the difference and try and run them on a number of
> vms.
>
> You'd be surprised at the things I've found, on one embedded vm
>
> x = (y == null) ? a : b;
>
> was 50% slower than
>
> if (y == null)
> x = a;
> else
> x = b;
>
> go figure.
Indeed. I would never dream of writing such a test.
x = (y == null) ? a : b;
is quicker to write than the other, and I like it. Such a difference in
performance is highly dependent on the particular compiler
implementation, and is subject to radical unannounced variation. I
would just write it and get on.
"I like it" is the acid test; for me, of all code, but in particular for
open source. Open source may be driven by many things, but money is not
one of them. Pleasure is, and is high on the list. In spite of that,
OS generates vast amounts of high-quality software. Go figure.
Peter
--
Peter B. West pbwest@powerup.com.au http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A performance patch for PDFInfo class
Posted by Kevin O'Neill <ke...@rocketred.com.au>.
On Tue, 2002-11-12 at 20:22, Laszlo Hornyak wrote:
> ok, sorry for the disturbance.
>
> Laszlo Hornyak
>
> ps:
> StringBuffering code:
> time for test: 45479
>
> String += code:
> time for test: 52011
>
> difference: 14.36%
>
> java version "1.4.1_01"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
I think everyone involved with FOP (from occasional contributors like
me, to the more stable and prolific commiters) appreciates the effort
you made. I wanted to ensure that your efforts where well directed and
you had the knowledge at had to increase the effectiveness of your
efforts.
Please never be sorry for disturbance, rock the boat, make me (and
others) explain our selves. I apologize if you took offense to my
remarks, none was intended.
I'm not doubting that the += is slower (that is plainly obvious from the
pcode). I do think that there are places for using StringBuffers, just
know when to use them.
> On Tue, Nov 12, 2002 at 09:13:36AM +0100, Keiron Liddle wrote:
> > On Mon, 2002-11-11 at 23:44, Kevin O'Neill wrote:
> > > Like anybody else there are times when I optimize as I go, but I really
> > > try and keep in mind, "is this the simplest thing I could do?" Fighting
> > > the urge to apply "optimizations" as you go is hard sometimes but in my
> > > experience leads to a better code base.
> >
> > This is the most important statement IMO.
> > Especially with Fop, if it is not simple there we are going to dig
> > ourselves into a hole.
> > Things are complicated enough without making convoluted and confusing
> > optimisations.
> >
> > Keep parts simple and have a well defined contract between parts.
> >
> > Keiron.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> > For additional commands, email: fop-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
--
If you don't test then your code is only a collection of bugs which
apparently behave like a working program.
Website: http://www.rocketred.com.au/blogs/kevin/
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A performance patch for PDFInfo class
Posted by Kevin O'Neill <ke...@rocketred.com.au>.
On Tue, 2002-11-12 at 20:22, Laszlo Hornyak wrote:
> ok, sorry for the disturbance.
>
> Laszlo Hornyak
>
> ps:
> StringBuffering code:
> time for test: 45479
>
> String += code:
> time for test: 52011
+= is slow
+ is faster.
> difference: 14.36%
>
> java version "1.4.1_01"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
> Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
>
>
>
> On Tue, Nov 12, 2002 at 09:13:36AM +0100, Keiron Liddle wrote:
> > On Mon, 2002-11-11 at 23:44, Kevin O'Neill wrote:
> > > Like anybody else there are times when I optimize as I go, but I really
> > > try and keep in mind, "is this the simplest thing I could do?" Fighting
> > > the urge to apply "optimizations" as you go is hard sometimes but in my
> > > experience leads to a better code base.
> >
> > This is the most important statement IMO.
> > Especially with Fop, if it is not simple there we are going to dig
> > ourselves into a hole.
> > Things are complicated enough without making convoluted and confusing
> > optimisations.
> >
> > Keep parts simple and have a well defined contract between parts.
> >
> > Keiron.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> > For additional commands, email: fop-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
>
--
If you don't test then your code is only a collection of bugs which
apparently behave like a working program.
Website: http://www.rocketred.com.au/blogs/kevin/
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A performance patch for PDFInfo class
Posted by Laszlo Hornyak <ho...@rootshell.be>.
ok, sorry for the disturbance.
Laszlo Hornyak
ps:
StringBuffering code:
time for test: 45479
String += code:
time for test: 52011
difference: 14.36%
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)
On Tue, Nov 12, 2002 at 09:13:36AM +0100, Keiron Liddle wrote:
> On Mon, 2002-11-11 at 23:44, Kevin O'Neill wrote:
> > Like anybody else there are times when I optimize as I go, but I really
> > try and keep in mind, "is this the simplest thing I could do?" Fighting
> > the urge to apply "optimizations" as you go is hard sometimes but in my
> > experience leads to a better code base.
>
> This is the most important statement IMO.
> Especially with Fop, if it is not simple there we are going to dig
> ourselves into a hole.
> Things are complicated enough without making convoluted and confusing
> optimisations.
>
> Keep parts simple and have a well defined contract between parts.
>
> Keiron.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: A performance patch for PDFInfo class
Posted by Keiron Liddle <ke...@aftexsw.com>.
On Mon, 2002-11-11 at 23:44, Kevin O'Neill wrote:
> Like anybody else there are times when I optimize as I go, but I really
> try and keep in mind, "is this the simplest thing I could do?" Fighting
> the urge to apply "optimizations" as you go is hard sometimes but in my
> experience leads to a better code base.
This is the most important statement IMO.
Especially with Fop, if it is not simple there we are going to dig
ourselves into a hole.
Things are complicated enough without making convoluted and confusing
optimisations.
Keep parts simple and have a well defined contract between parts.
Keiron.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: A performance patch for PDFInfo class
Posted by Kevin O'Neill <ke...@rocketred.com.au>.
<snip/>
> > So the first recommendation is to use String "+" for this type of
> > method, it's easier to read and runs faster.
> [ SNIP ]
>
> This kind of thing is discussed by Jack Shirazi at length, also.
>
> The thing is, there has long been a blanket instruction, don't use String
> concatenation. Programmers learn it by fiat, and never think it through. In
> fact, it should be obvious to any programmer (if they are encouraged to
> think, that is) that concatenation of literal Strings is not something to
> avoid. Assuming a decent compiler.
You've hit the nail on the head. Optimizations are just that
optimizations. They are not "blanket application" things.
Like anybody else there are times when I optimize as I go, but I really
try and keep in mind, "is this the simplest thing I could do?" Fighting
the urge to apply "optimizations" as you go is hard sometimes but in my
experience leads to a better code base.
When you do apply an optimization, prove it's worth. Create a small set
of tests that show the difference and try and run them on a number of
vms.
You'd be surprised at the things I've found, on one embedded vm
x = (y == null) ? a : b;
was 50% slower than
if (y == null)
x = a;
else
x = b;
go figure.
-k.
--
If you don't test then your code is only a collection of bugs which
apparently behave like a working program.
Website: http://www.rocketred.com.au/blogs/kevin/
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: A performance patch for PDFInfo class
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
> -----Original Message-----
> From: Kevin O'Neill [mailto:kevin@rocketred.com.au]
> Sent: November 11, 2002 5:47 PM
> To: FOP Developers
> Subject: Re: A performance patch for PDFInfo class
>
[ SNIP ]
> String buffers are used by the compiler to implement the binary string
> concatenation operator +. For example, the code:
>
> x = "a" + 4 + "c"
>
>
> is compiled to the equivalent of:
>
> x = new StringBuffer().append("a").append(4).append("c")
> .toString()
>
>
> So the first recommendation is to use String "+" for this type of
> method, it's easier to read and runs faster.
[ SNIP ]
This kind of thing is discussed by Jack Shirazi at length, also.
The thing is, there has long been a blanket instruction, don't use String
concatenation. Programmers learn it by fiat, and never think it through. In
fact, it should be obvious to any programmer (if they are encouraged to
think, that is) that concatenation of literal Strings is not something to
avoid. Assuming a decent compiler.
Regards,
AHS
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: A performance patch for PDFInfo class
Posted by Kevin O'Neill <ke...@rocketred.com.au>.
Sorry if this seems hard but this is the sort of performance enhancement
I was talking about yesterday. If people are going to do these sorts of
"enhancements" then they should be aware of the effects.
It's always easier to work with examples.
public class StringTest
{
// String Buffer
public String testStringBufferStraightCall()
{
StringBuffer sb = new StringBuffer();
sb.append("this ");
sb.append(makeString("is "));
sb.append("a ");
sb.append(makeString("test"));
return sb.toString();
}
public String testStringBufferChained()
{
StringBuffer sb = new StringBuffer();
sb.append("this ")
.append(makeString("is "))
.append("a ")
.append(makeString("test"));
return sb.toString();
}
public String testStringAdd()
{
return
"this "
+ makeString("is ")
+ "a "
+ makeString("test");
}
public String testIncrement()
{
String result = "this ";
result += makeString("is ");
result += "a ";
result += makeString("test.");
return result;
}
private String makeString(String testString)
{
return testString;
}
}
Which of the above is faster?
A simple timer test will show that testStringAdd() is the fastest,
followed closely by testStringBufferChained(). For the reason why, lets
look at the byte-code.
Method java.lang.String testStringBufferStraightCall()
0 new #2 <Class java.lang.StringBuffer>
3 dup
4 invokespecial #3 <Method java.lang.StringBuffer()>
7 astore_1
8 aload_1
9 ldc #4 <String "this ">
11 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
14 pop
15 aload_1
16 aload_0
17 ldc #6 <String "is ">
19 invokespecial #7 <Method java.lang.String
makeString(java.lang.String)>
22 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
25 pop
26 aload_1
27 ldc #8 <String "a ">
29 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
32 pop
33 aload_1
34 aload_0
35 ldc #9 <String "test">
37 invokespecial #7 <Method java.lang.String
makeString(java.lang.String)>
40 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
43 pop
44 aload_1
45 invokevirtual #10 <Method java.lang.String toString()>
48 areturn
Method java.lang.String testStringBufferChained()
0 new #2 <Class java.lang.StringBuffer>
3 dup
4 invokespecial #3 <Method java.lang.StringBuffer()>
7 astore_1
8 aload_1
9 ldc #4 <String "this ">
11 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
14 aload_0
15 ldc #6 <String "is ">
17 invokespecial #7 <Method java.lang.String
makeString(java.lang.String)>
20 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
23 ldc #8 <String "a ">
25 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
28 aload_0
29 ldc #9 <String "test">
31 invokespecial #7 <Method java.lang.String
makeString(java.lang.String)>
34 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
37 pop
38 aload_1
39 invokevirtual #10 <Method java.lang.String toString()>
42 areturn
Method java.lang.String testStringAdd()
0 new #2 <Class java.lang.StringBuffer>
3 dup
4 invokespecial #3 <Method java.lang.StringBuffer()>
7 ldc #4 <String "this ">
9 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
12 aload_0
13 ldc #6 <String "is ">
15 invokespecial #7 <Method java.lang.String
makeString(java.lang.String)>
18 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
21 ldc #8 <String "a ">
23 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
26 aload_0
27 ldc #9 <String "test">
29 invokespecial #7 <Method java.lang.String
makeString(java.lang.String)>
32 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
35 invokevirtual #10 <Method java.lang.String toString()>
38 areturn
Method java.lang.String testIncrement()
0 ldc #4 <String "this ">
2 astore_1
3 new #2 <Class java.lang.StringBuffer>
6 dup
7 invokespecial #3 <Method java.lang.StringBuffer()>
10 aload_1
11 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
14 aload_0
15 ldc #6 <String "is ">
17 invokespecial #7 <Method java.lang.String
makeString(java.lang.String)>
20 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
23 invokevirtual #10 <Method java.lang.String toString()>
26 astore_1
27 new #2 <Class java.lang.StringBuffer>
30 dup
31 invokespecial #3 <Method java.lang.StringBuffer()>
34 aload_1
35 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
38 ldc #8 <String "a ">
40 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
43 invokevirtual #10 <Method java.lang.String toString()>
46 astore_1
47 new #2 <Class java.lang.StringBuffer>
50 dup
51 invokespecial #3 <Method java.lang.StringBuffer()>
54 aload_1
55 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
58 aload_0
59 ldc #11 <String "test.">
61 invokespecial #7 <Method java.lang.String
makeString(java.lang.String)>
64 invokevirtual #5 <Method java.lang.StringBuffer
append(java.lang.String)>
67 invokevirtual #10 <Method java.lang.String toString()>
70 astore_1
71 aload_1
72 areturn
So the answer is the compiler converts String additions to
StringBuffer.append(). Because it's done at the compiler level it can
also do optimizations that can't be done at the java code level (look at
the number of loads and pops). Quoting from the StringBuffer javadoc.
String buffers are used by the compiler to implement the binary string
concatenation operator +. For example, the code:
x = "a" + 4 + "c"
is compiled to the equivalent of:
x = new StringBuffer().append("a").append(4).append("c")
.toString()
So the first recommendation is to use String "+" for this type of
method, it's easier to read and runs faster.
So why would you use StringBuffer at all? Notice that the String
concatenation calls the no argument constructor for StringBuffer. On my
vm this means that a 16 char StringBuffer is allocated, this means in
the sample above it will grow at least once creating garbage and
allocating memory, both can be slow operations. So for large String
concatenation in PERFORMANCE SENSITIVE areas, create a StringBuffer of
at least the size you need by calling StringBuffer(SIZE) and use chained
StringBuffer calls. StringBuffers can carry a single instance through
loops, String concatenation can't.
Note: The hotspot vms are very hard to profile, especially in server
situations. You'll need to warm the code to ensure that hotspot has had
a chance to apply its optimizations.
This is in an area of code that is run once per invocation of the PDF
writer, there is no way this would show up as a hot spot in a profile.
It is better than += but it's harder to read. If these sort of
"optimizations" are going to be done, then they should be done in an
informed manor and using an understanding of the effect to create truly
optimized code rather than a sort of optimized mess. My opinion in this
case would be to convert it to use the "+" operator. It's not a
performance critical area, '"foo" + "bar"' is easier to read than
sb.append("foo").append("bar") and lastly the next version of the
compiler may have some new optimizations that take care of the sizing
issue.
Food for thought.
-k.
--
If you don't test then your code is only a collection of bugs which
apparently behave like a working program.
Website: http://www.rocketred.com.au/blogs/kevin/
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org