Poor perfomance in fetching a set of entities. State/Stateless session mode

[korchak-aleksandr]

Why NH 5.1 in session mode and in stateless session mode shows same results?
For example benchmark in https://github.com/FransBouma/RawDataAccessBencher

I forked this project: https://github.com/sanekpr/RawDataAccessBencher/
And I create NH behch with stateless session mode.

And my results for fetch set test:

1. EF Core 2.1 (no change tracking) - 202ms
2. Dapper 1.50 - 221 ms
3. NH 5.1 (stateless mode) - 2 055 ms

May be I made smth wrong? Or stateless mode doesn't affect on fetch set perfomance?

[fredericDelaporte]

You can read some considerations in FransBouma/RawDataAccessBencher#9 comments.

[korchak-aleksandr]

@fredericDelaporte as you write in that comment I create the implementation with Stateless Session. But perfomance is almoust the same as with session.

May be loading entities as readonly objects fixes this?
And how can I load set or single entity as readony in methods Get or Query ?

[fredericDelaporte]

I am referring to:

By the way, if by "tracking" it is understood something like "the ORM is somehow notified of changes on entities", there are indeed currently no tracking at all in NHibernate

There are no such mechanism in NHibernate, so going stateless has no impact on the entities themselves.

Instead, NHibernate keeps in the session a snapshot of the state of each loaded entity at the time it was loaded, and on flush, check each entity current state against the snapshot for detecting if the entity was changed.

The bulk of the work is the dirty check, which only occurs on flush. So on read usages, the dirty check has no impact. Storing a copy of the loaded state is of course done on read in a normal session, but it has mainly a memory impact.

[korchak-aleksandr]

So, at this moment EFCore demostrate 10x faster perfomance in fetching sets of entities.
No doubt that NHibernate has 10x rich capabilities, and it would be right that perfomance is at least the same :-)

@fredericDelaporte @hazzik,
Would you plan some perfomance improvement to read scenarios in future releases?

[fredericDelaporte]

For me the answer is no, it is not my priority to optimize for a benchmark.

Anyway, benchmarks are usually far from reflecting performances in actual usage cases. They may help checking optimizations actual gains, but using them for comparing tools having vastly different implementation principles, drawbacks and benefits, is generally a bit moot.

[korchak-aleksandr]

@fredericDelaporte I'm not ask you to optimize NH perfomance for this benchmark.

I ask you to add in some task plan general optimization in fetching set of entities from database.
Do you think it's not important task?

[fredericDelaporte]

Anyway, benchmarks are usually far from reflecting performances in actual usage cases. They may help checking optimizations actual gains, but using them for comparing tools having vastly different implementation principles, drawbacks and benefits, is generally a bit moot.

I mean this benchmark does not prove there is an actual need for optimizing fetching.

Of course you are free and welcome to investigate this subject by yourself and find-out any optimization which could be done in the code base.

We do care about performances, provided evidence of implementation points requiring some work are provided, like in #1391 (or #1446, followed by #1455).

[hazzik]

This is the culprit for the poor performance of a stateless session:

nhibernate-core/src/NHibernate/Impl/StatelessSessionImpl.cs

Line 73 in 14c5cdb

return persister.CreateProxy(id, this);

Stateless session creates proxies for associations. However these proxies will not be able to be resolved into the entities as stateless session does not support proxies. In my current setup creation of these proxies takes around 33% of the execution time (most of the time is taken by constructors thou).

[bahusoid]

However these proxies will not be able to be resolved into the entities as stateless session does not support proxies.

So are you saying that new Entity() vs proxy creation makes so much a difference. But why? Shouldn't static proxy generator be some equivalent of "new EntityProxy()" call?

I see that persister.CreateProxy leads to series of calls that end up in concurrent dicitionary lookup each time. Can't it be the reason for slowleness?

Maybe we should extend IProxyFactory to return proxy activator delegate. Something like:
Func<object, ISessionImplementor, object> GetProxyActivatorDelegate;

Then I think we can cache this delegate inside persister.

[hazzik]

No. The entities' constructors have 80% of the impact.

[hazzik]

So, in case of StatelessSession GetProxy takes 305ms our of 1000ms: Most of the time it spends in GC. I believe this is because it needs to clear the heap to put these objects there.