aspose file tools*
The moose likes Performance and the fly likes Need your expert opinion! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "Need your expert opinion!" Watch "Need your expert opinion!" New topic
Author

Need your expert opinion!

ALeX
Greenhorn

Joined: Sep 19, 2003
Posts: 4
Anyone please help?
I am in a debate with the vendor about the following. In a web application, they convert all input into uppercase using String toUpperCase. Their reasoning is it helps with quering the data in a search (test vs Test). I suggest storing data as entered (filtering special characters, etc) and use SQL Server upper/lower function instead. Eg, for search criteria last=t*, query would be:
select * from user where upper(last) like upper('t%').
A small query analysis does show a performance decrease with using the function vs
select * from user where last like('T%'), given all data is CAPITALIZED

So, what is more memory expensive, given about 20 simultaneous users, calling toUpperCase when passing values into a database, or described above?
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Originally posted by A Len:
So, what is more memory expensive, given about 20 simultaneous users, calling toUpperCase when passing values into a database, or described above?

Your database may have the concept of a function-based index. In Oracle, you can index upper(column) to improve performance. To query you do

That would solve the performance issues you're seeing. If that's not an option, it means doing the search will result in a full table scan. For 50 rows, no big deal. For 1 million users, eek!
As to the wasted memory of uppercasing the strings, 1) they're probably short, 2) String doesn't take that much memory, and 3) the objects are short-lived and the JVM can optimize their use pretty well. I wouldn't worry about it; not when you're talking about wasting a few kibibytes here and there.
ALeX
Greenhorn

Joined: Sep 19, 2003
Posts: 4
appreciate your response!
I haven't seen the code yet, so there are many blanks. Database is MS SQL2000 Enterprise, running on a multi-processor server. Web app is Struts-based, with Tomcat 4.1.29 running on another multiprocessor box. Both are Windows 2000 Server. I am trying to troubleshoot the outOfMemory problems. Before spending too much time with JVM performance tuning, I want to make sure all other 'more obvious' issues are taken care of.
So, for the following scenario:
For 10 new records submitted by multiple users, containing about 30 fields each, 20 are strings that are capitalized, there are no memory problems? If these operations are indeed short-lived and do not affect JVM's performance, then I'll look for other problems.
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Originally posted by ALeX:
For 10 new records submitted by multiple users, containing about 30 fields each, 20 are strings that are capitalized, there are no memory problems? If these operations are indeed short-lived and do not affect JVM's performance, then I'll look for other problems.

Let's assume the average string size for those fields is 40 characters. So with 20 string fields per object, a base size of 12 bytes for a String, and 2 bytes per character, you're using about 1840 bytes for temporary uppercase versions of those fields per object. Of course, the non-uppercased fields that came from the web layer are also temporary and of the same size.
This isn't much memory, and it's happening all the time. If your JVM is recent, it should have an improved GC that deals with temporary object creation more robustly. I suspect there's a bigger problem somewhere, whether you're caching too many objects or keeping references around that should be nulled.
Joe Ess
Bartender

Joined: Oct 29, 2001
Posts: 8971
    
    9

And for pete's sake invoke close() on your ResultSet, Statement and Connection objects (or return Connections to your connection pool). Probably the greatest single cause of memory leaks in web apps.


[How To Ask Questions On JavaRanch]
ALeX
Greenhorn

Joined: Sep 19, 2003
Posts: 4
Thank you all for a valuable feedback.
FYI, I found out something that I actually forgot. When creating a database in SQL Server, you can specify case-incensitive or case-sensitive search using collation (by default, it is set to case-incensitive).
For Doe, John search query
select * from user where lname like ('d%') and fname like ('j%')
returns the same results as
select * from user where lname like ('D%') and fname like ('J%')
ALeX
Greenhorn

Joined: Sep 19, 2003
Posts: 4
Originally posted by David Harkness:

Let's assume the average string size for those fields is 40 characters. So with 20 string fields per object, a base size of 12 bytes for a String, and 2 bytes per character, you're using about 1840 bytes for temporary uppercase versions of those fields per object. Of course, the non-uppercased fields that came from the web layer are also temporary and of the same size.
This isn't much memory, and it's happening all the time. If your JVM is recent, it should have an improved GC that deals with temporary object creation more robustly. I suspect there's a bigger problem somewhere, whether you're caching too many objects or keeping references around that should be nulled.

I do not have the source code for the server-side. I can only analyse the results, unfortunately, at this time. My main concern was with java.lang.outOfMemory exception. Webapp is running on Tomcat4.1.29(jdk1.4.1_02)/Struts1.1 on Windows 2000 Server, on a powerful multiprocessor server with 4Gb memory. I have been tuning JVM's GC options, but without the source code I can mostly guess where the problems are. Next week, I will load JProbe - hope it will show which classes stress CPU the most.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Need your expert opinion!