It has been a few years since I timed the difference, but it used to be the case for Oracle drivers that creating a prepared statement cost 3x or 4x that of a regular statement.
Actually, at least as far back as the 8.1.7 driver, the difference isn't nearly that high. However many people have ended up with false results in their casual timing tests because in the Oracle driver, getConnection will use a Statement internally. Folks then end up comparing the time between "execution time of Statement" versus "class load time + execution time of PreparedStatement"; class load time can be pretty significant.
A correctly run single-threaded timing test with (apparently) the 9i driver on a 9i database produced these results:
Rows to Insert Statement PrepareStatement
1 0.05 seconds 0.05 seconds
10 0.30 seconds 0.18 seconds
100 2.69 seconds 1.44 seconds
1000 28.25 seconds 15.25 seconds
http://asktom.oracle.com/pls/ask/f?p=4950:8:14323156943165993748::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:10128287191505 A muti-threaded test should show even more dramatic differences, especially with a database on a muti-CPU machine or RAC cluster.
Even very very rarely used SQL that has different data values should almost always be executed using PreparedStatement with data bindings; this is even more true in a RAC cluster. There are a very very very few exceptions to that rule of thumb though, involving data skew, where clauses, and indexes; even in those cases,
you should use PreparedStatement, but then not bind the where clause value.