Viks wrote:
Hi,
My app is running out of app.
Code does a lot of string opeartion.It involves fetching records from DB
Initially i was using string objects- Program used to finish in about 40-45 min with ~95 cpu usage
String concatenation like this String c = a+b; is done internally like
this in java:
String c = new StringBuffer(a).append(b).toString();
This explains why String is slower than StringBuffer.
We did some optimization on the code like changing the query from String to StringBuffer.
If you go java 1.5, prefer StringBuilder, it's not synchronized and as
such works way faster on multi CPU computers (a synchronization is a
costy operation on multi core / multi CPU systems, even if you only have
one thread)
This has improved the execution time and cpu usage.
For 60k records the prog ran fine ....execution time improved from 30 mins to around 4 min and cpu usage from 95 % to 15%.
For around 100k records my apps goes down on memory.
Wondering if the app is able to sustain on String Obj why it is going down with StringBuffer Objects.
String buffer, for performance reasons, have a somehow particular way of
handling their growable array. Because a StringBuffer could be subject
to 3 or 4 append() calls in a row (like when you do "This a message from
"+sender+" to "+receiver), it increase it's internal array a bit more
then needed to prevent multiple useless array expansion which is
something costy. StringBuffer always attempts in sun implementation, to
double it's internal array when it has become too short. If it's still
not enough, it increase it to requested size. Here is code of
'ensureCapacity' from the sun implementation (subject to sun licence):
char value[];
....
void expandCapacity(int minimumCapacity) {
int newCapacity = (value.length + 1) * 2;
if (newCapacity < 0) {
newCapacity = Integer.MAX_VALUE;
} else if (minimumCapacity > newCapacity) {
newCapacity = minimumCapacity;
}
char newValue[] = new char[newCapacity];
System.arraycopy(value, 0, newValue, 0, count);
value = newValue;
}
As a result, a stringbuffer can take up to about 2 times the size of
corresponding String (worst case)
I suggest, when you are sure a StringBuffer will not be modified anymore
in near future, convert it back to String
btw, simply increase the jvm allocated size is a good way to go away
with out of memory if you don't want to spend lots of time optimizing
your code.
Last but not least, what does it have to do with tomcat??
Viks
---------------------------------
Here’s a new way to find what you're looking for - Yahoo! Answers
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
