This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
I've heard that using JDBC in some circunstances can make the application faster than using JPA, because you don't need to transform the tables in entities. For an instance, I have a batch program that run a Java class to process every night at 11:30 pm. In this case using JDBC is better than JPA, concerning about performance?
Since this answer answers all comparative performance questions, I'll flesh it out a bit. JDBC requires more boiler plate code written so is liable to take longer to write in the first place and more effort to maintain. Given the trade off between the cost of hiring a developer against the cost of buying a more powerful computer, this is often the performance metric people look to.
JPA has things JDBC doesn't have, namely caching, so in a normal transactional application a properly implemented and tuned JPA solution should at least compare favourably with JDBC, and may be faster. However, your application is a batch processing application. This is the one area that ORMs do not do well (they were never really designed to do this job). JDBC is liable to be better here, however if this is a single database batch process, and performance is your key metric, JDBC will not compare with a 100% database solution. You might be better off with a bunch of stored procedures.
The other thing to ask when you think of performance is "do I have a performance problem"? No sense rewriting an application to run 25% faster if it completed in an acceptable time frame anyway. Step one before doing any performance tuning is benchmarking.