JDBC PreparedStatements

Post #25,309 by dlevitt 1/23/02 3:07:12 PM Reply	JDBC PreparedStatements The strings are used in the creation of PreparedStatements - oddly enough, we are reconsidering the use of PreparedStatements based on some information in an O'Reilly book on Oracle & JDBC - the sample chapter on the web site shows that [in the autor's tests] PreparedStatement operations are slower than other Statements.
Post #25,366 by admin 1/23/02 8:12:59 PM Reply	Depends on the database I've seen that assertion in regards to SQL Server, but not Oracle. Link? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #25,367 by admin 1/23/02 8:14:02 PM Reply	But back to the main question... Why are you spending so much time worrying about a few Strings if they only get used once? Use a performance profiling tool and find your real bottlenecks, instead of guessing. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #25,368 by wharris2 1/23/02 8:28:00 PM Reply	Yeeha, Scott But you wouldn't believe (er, on second thought, maybe you would) the companies that won't spend $500 or $1000 (or whatever it is, I think the max cost I've seen was $3000) on a profiling tool that really seeks out inefficiencies. On second thought, many of the profiling tools I've used under Unix became worthless when compiled with vendor's object-only libraries. cc compiled with profiling (with third-party object libraries) loses itself in untracable links more often than not, in my experience. "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
Post #25,373 by admin 1/23/02 8:41:49 PM Reply	Java profiling usually works pretty well I'll dig up some links. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #25,376 by wharris2 1/23/02 8:55:56 PM Reply	I believe that, no links required Unless they call native code, Java classes are reasonably exposed to a profiler. Alas, I've run into C code that ran into the roadblock of vendor libraries. You can get some good information out of cc compiled for gprof, but many times it is only tantalizing as to where it leads you. "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
Post #25,386 by slugbug 1/23/02 9:27:03 PM Reply	Try: JProbe...
Post #25,454 by drewk 1/24/02 10:32:07 AM Reply	Oh I believe it Like the people I've talked to who don't like using generalized functions stored in Postgres. They prefer to hand tune the queries. When you're querying terrabytes of data, maybe. But we were talking about a templating system for a (fairly) low-volume extranet. Take the money you save in developers' time ( ten minutes per query X several dozen pages ) and double the amount of RAM in your webserver. There are times throwing hardware at it is the solution. Otherwise we'd all be writing in assembly. We have to fight the terrorists as if there were no rules and preserve our open society as if there were no terrorists. -- [link\|http://www.nytimes.com/2001/04/05/opinion/BIO-FRIEDMAN.html\|Thomas Friedman]
Post #25,455 by admin 1/24/02 11:03:56 AM Reply	Kinda missing the point... ... the point is to optimize the stuff that gets run often. Loops, queries, repeated operations. Not one-time inits, or static vs. non-static strings that are used once as in this case. The profiler will tell you what's taking the most time in the app. Hit the hot spots with the optimizations and you'll get the most return for your time. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."

Welcome to IWETHEY!