«

Is there complied list of the hints and tips for fast and improved
performance Java code? e.g. something like: in concatenation use
StringBuffer instead of String.

Thanks in advance,
Ahmed

On Mon, 14 Jul 2003 18:44:57 -0400, Ahmed Moustafa wrote
(in message <JnGQa.100951$ ink.net>):

> Is there complied list of the hints and tips for fast and improved
> performance Java code? e.g. something like: in concatenation use
> StringBuffer instead of String.
>
> Thanks in advance,
> Ahmed
>

If you are using ArrayList (or any type of collection ) and adding a lot
objects, set the size of the ArrayList to the largest number you can think
of. Example, if you think you might insert 20000 objects into the List, then
create the ArrayList with 20000 entries.

You can do this with the StringBuffer also.

J

> Is there complied list of the hints and tips for fast and improved
> performance Java code?
Look at http://www.javaperformancetuning.com

Also for monitoring performance check out a free tool with source code
I've written called JAMon.

steve - http://www.jamonapi.com

>>Is there complied list of the hints and tips for fast and improved
>>performance Java code? e.g. something like: in concatenation use
>>StringBuffer instead of String.
>>
>
> If you are using ArrayList (or any type of collection ) and adding a lot
> objects, set the size of the ArrayList to the largest number you can think
> of. Example, if you think you might insert 20000 objects into the List, then
> create the ArrayList with 20000 entries.

How many would be "a lot"?
How about reading records from a ResultSet and no expectation the number
of records there?

> You can do this with the StringBuffer also.

Ike <> wrote:
> http://www-2.cs.cmu.edu/~jch/java/optimization.html

Note that that site has been "retired" for over 5 years, so I would
take all comparitive benchmarks on there as almost certainly bogus now.

--
Jon Skeet - <>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

> http://www-2.cs.cmu.edu/~jch/java/optimization.html

I have seen it before. It's out of date, isn't?

Ahmed Moustafa wrote:
> Is there complied list of the hints and tips for fast and improved
> performance Java code? e.g. something like: in concatenation use
> StringBuffer instead of String.

I've always been impressed with:
http://www.precisejava.com/

There is even a discussion regarding String concatenation there at:
http://www.precisejava.com/javaperf/...htm#Strings104

HTH,

--
-Scott
| http://www.yanoff.org | AOL IM: SAY KJY

Yikes! I hadnt even reaslise...thanks. -Ike

"Jon Skeet" <> wrote in message
news:. ..
> Ike <> wrote:
> > http://www-2.cs.cmu.edu/~jch/java/optimization.html
>
> Note that that site has been "retired" for over 5 years, so I would
> take all comparitive benchmarks on there as almost certainly bogus now.
>
> --
> Jon Skeet - <>
> http://www.pobox.com/~skeet/
> If replying to the group, please do not mail me too
>

In article <JeLQa.2536$ .net>,
Ahmed Moustafa <> wrote:

> >>Is there complied list of the hints and tips for fast and improved
> >>performance Java code? e.g. something like: in concatenation use
> >>StringBuffer instead of String.
> >>
> >
> > If you are using ArrayList (or any type of collection ) and adding a lot
> > objects, set the size of the ArrayList to the largest number you can think
> > of. Example, if you think you might insert 20000 objects into the List,
> > then
> > create the ArrayList with 20000 entries.
>
> How many would be "a lot"?
> How about reading records from a ResultSet and no expectation the number
> of records there?

That is actually the easy case - profile!

If you instrument your code with unit tests, you might build a few tests
designed to test the runtime performance. Make up a test dataset that
returns the number of records you feel you need to handle elegantly, and
also make up test sets for "typical" and "minimal" cases, and set
definite requirements.

If you decide that your test set will work very quickly for 0 to 50
returned objects, but that it should handle 100, 1000, and 10000 without
breaking a sweat, and that it should handle records with a dozen or two
dozen fields without a problem, but you will handle 256 VARCHAR255's
full of data, then your test suite is pretty easy to build. Further, by
going an order of magnitude beyond your anticipated needs, you can
usually spot n^2 problems early in the design phase.

I am a fan of not optimizing until I have a use case that shows me
_what_ to optimize. Just trying to "make things faster" rarely is a
good idea, unless you have a really clear image of what the code is
supposed to do, and once you have that, you might as well translate that
image into definitive test cases run on every build.

Scott

When a PreparedStatement gets created and then the Connection is closed,
does the database keep the PreparedStatement somewhere? If so, when the
statement gets created again, how can the database related the old
complied one to the new one?