Você pode fazer um teste de fumaça com a consulta simples possível como:
SELECT current_timestamp()
ou
SELECT 1 + 1
Isso lhe dirá qual é a sobrecarga real do driver JDBC. Também não está claro se ambos os testes são realizados na mesma máquina.
Execute a mesma consulta milhares de vezes em Java. A JVM precisa de algum tempo para aquecer (carregamento de classe, JIT). Também assumo
SimpleJDBC.getConnection() usa o pool de conexão C3P0 - o custo de estabelecer uma conexão é bastante alto, então as primeiras execuções podem ser lentas. Prefira também consultas nomeadas a consultas ad-hoc ou consultas de critérios.
O Hibernate é um framework muito complexo. Como você pode ver, ele consome 75% do tempo total de execução em comparação com o JDBC bruto. Se você precisar de ORM bruto (sem carregamento lento, verificação suja, cache avançado), considere mybatis . Ou talvez até
JdbcTemplate
com RowMapper
abstração. Na verdade. Confira o Capítulo 19. Melhorando o desempenho na documentação do Hibernate. Há muito de reflexão acontecendo lá fora + geração de classe. Mais uma vez, o Hibernate pode não ser a melhor solução quando você deseja extrair cada milissegundo do seu banco de dados.
No entanto é uma boa escolha quando você deseja aumentar a experiência geral do usuário devido ao amplo suporte ao cache. Confira o desempenho doutor novamente. Ele fala principalmente sobre cache. Existe um cache de primeiro nível, cache de segundo nível, cache de consulta... Este é o lugar onde o Hibernate pode realmente superar o JDBC simples - ele pode armazenar muito em cache de maneiras que você nem imagina. Por outro lado, uma configuração de cache ruim levaria a uma configuração ainda mais lenta.
Confira:Cache com Hibernate + Spring - algumas perguntas!
JVM (especialmente em servidor configuração) é bastante rápido. A criação de objetos no heap é tão rápida quanto na pilha, por exemplo. C, a coleta de lixo foi bastante otimizada. Eu não acho que a versão Java executando JDBC simples seria muito mais lenta em comparação com uma conexão mais nativa. É por isso que sugeri algumas melhorias em seu benchmark.
Acredito que o JDBC seja uma boa escolha se o desempenho for seu maior problema. Java tem sido usado com sucesso em muitos aplicativos de banco de dados pesados.
