Don't be! I think this discussion is very healthy. Thanks to all who
are participating.
On 15 Nov 2002 08:50:19 +1100 Kevin O'Neill wrote:
> ps: Sorry if this is boring anyone :(.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMA
Tom,
> I know I also came in late into this thread. I would like to say I am very
> excited about the possibilities of FOP in the future and the already
> realized gains FOP gives. My overall grasp of FOP at this moment is still
> limited but I have been delving into the code and using it for a cu
#x27;Neill"
com.au> cc: (bcc: Thomas
Seremet/GCR-NAmerica/GRN)
Subject: Re: A performance patch
-12 20:26
Please respond to fop-dev
To: FOP Developers <[EMAIL PROTECTED]>
cc:
Subject: Re: A performance patch for PDFInfo class
On Wed, 2002-11-13 at 02:25, Henrik Olsson wrote:
> >StringBuffer xxx.append("foo").append("bar");
>
> Some more insight or confusion. The byte code maybe similar in the sense
> that String uses "".concat() and
> StringBuffer uses new StringBuffer().append to do their individual
> concatenations but the way they are
> treated by the JVM is not the same. Of course not all JVM's are created
> equa
#x27;Neill"
com.au> cc: (bcc: Thomas
Seremet/GCR-NAmerica/GRN)
Subject: Re: A performance patch
On Wed, 2002-11-13 at 02:25, Henrik Olsson wrote:
> >StringBuffer xxx.append("foo").append("bar");
> >
> >understanding what the compiler does is the secret to optimizing
> >Strings.
>
> Hi Kevin.
> Its not an issue of what code is fastest here, its about creation and
> destuction of objects.
Th
Henrik Olsson wrote:
Sad to here that, I think that it should be considered while you design
and create functionality.
Real optimizations should take place only after careful measurements, which
possible only when your stuff works, but you cannot design, prototype or
implement with optimizati
Keiron Liddle wrote:
> Surely functionality and design count before optimisations.
Sad to here that, I think that it should be considered while you design and create functionality.
Since the FOP are realy doing the job for me, just some prefomeance issue.
/Henrik
On Tue, 2002-11-12 at 16:25, Henrik Olsson wrote:
> >StringBuffer xxx.append("foo").append("bar");
> >
> >understanding what the compiler does is the secret to optimizing
> >Strings.
>
> Hi Kevin.
> Its not an issue of what code is fastest here, its about creation and
> destuction of objects.
Su
>StringBuffer xxx.append("foo").append("bar");
>
>understanding what the compiler does is the secret to optimizing
>Strings.
Hi Kevin.
Its not an issue of what code is fastest here, its about creation and destuction of objects.
I have done several measurements on the fop to find the bottlenecks a
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
On Tue, 2002-11-12 at 22:24, Henrik Olsson wrote:
> >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 sl
>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.
>
The important thing here are not realy the time it tak
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 Runti
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, mix
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 bet
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 ge
On Tue, 2002-11-12 at 11:21, Peter B. West wrote:
> Kevin O'Neill wrote:
> >
> >
> >>>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 l
Kevin O'Neill wrote:
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
> > 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. P
> -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 bin
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
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
pu
24 matches
Mail list logo
