To fetch 100 users at once, i used JPA hibernate findAll() method. Simple fucking enough. I realized this shit is slow. Takes a while to fetch and 100 records aint even a lot!

This shit needs over 265 ms to fetch 100 users

About 75 ms to fetch 20 users

That shits terrible!

Then i wrote a custom JDBC class with custom SQL queries to fetch the exact same shit.

Now it fetched 100 users in 7 ms, 37x times faster for performance

I havent even optimized indexing or did shit. I just avoided using jpa hibernate

Someone explain this to me

If there are FKs and your pojo states that with having child pojos. It will try to load all the rows from the foreign indexes too

That's ORMs for you. Simplicity at the expense of performance.

State tracking, local caching, record type > field type mapping, pojo creation and values' setting via reflection, inner collections/pojo fields fetching and mapping to pojos, ... And that's not all.

Tremendous overhead, yes. Tremendous lack of flexibility. For the sake of simplicity.

After my share of years of experience I've come to realize that JPA is perfect for MVPs, POCs or small projects. It is a factor significantly holding back development and performance in large projects.

Is it tracking changes? Entity framework does that and it can slow loading lots of records, but you can tell it not to when you don't need it.

Also lol 256ms sure it can be better but maybe cry when you have a real problem, like my analytics people running queries that take literal minutes and being perfectly happy with that, meanwhile the DB is having an asthma attack.

Use Jooq.

@spongessuck Yes it is. It tracks pristine/dirty entities in order to only make _write_ calls to DB when records are dirty. There's also an enormous amount of merges going on in the background - something I've come to treat as a BAU in my profiler snapshots... According to my profiler (and series of TDumps), merges are quite heavy and slow operations.

And I wouldn't even say that the "simplicity" argument is a valid one. "simplicity" only applies to dead simple operations. So you have to design your services/interactors to play according to the ORM's rules, in order to not upset it, to make it easy for it. In essence, you're designing your architecture to be ORM-friendly. If you need anything more advanced - here be dragons. ORM will definitely show its teeth and quickly burn through your ibuprofen reserves by pulling its FRUSTRATION card. And it will keep on doing it until you budge and design your code to be ORM-friendly.

JPA is alright, it's a sound abstraction. ORM isn't

@gymmerDeveloper yes there are but they are set to lazy load (which improved performance twice as much but was still slow)