Hi to all,

we have quite a large data model consisting of about 500 persistent classes, 6000 properties and 500 associations.

Since the model is highly interconnected with associations, I believe we need to load all of the resulting mapping files at startup.

I can live with the startup time it takes to read the mappings and build the session factory. It takes about 5 seconds on me dev-machine. In fact, I think it is very fast if I consider all the work that needs to be done.

What worries me more is the memory consumption. Right after having built the session factory, my app already needs 50 mb. Most of this memory is alloceted in private memory segments and cannot be shared among processes. The memory consumtion seems to be related to the Persisters that are created during startup.
We plan to run our app's on Terminal Servers or Citrix Servers. So I think this memory footprint will cause us problems.

Since in normal usage of the application, an end-user will typically not use all features of the app, most of the available classes ill never be used. The problem is: I don't know in advance which classes will get used and which not.
So my idea is: if there would be a way to create the EntityPersister only on demand, whenever the class is actually used for the first time, we could reduce the footprint to what is really needed.

Is there a way to do this?
Do you think such a feature would make sense and could be accomplished?
Is there another way to avoid this problem?

Thanks for any input.

50Mb sounds about right for a big .Net app startup.
Try initializing NH in an empty console app, and measure the differences.

Hi Ayende,
thank you for your reply.
I already measured the memory consumption with a striped down console application.
What I did not realize is the fact that task manager is showing working set size and virtual bytes counters that seem to be too high.
After having memory profiled the console app I know that NHibernate really uses "only" 18 MB of memory on the manged heap.
I examined the code that is run during building the session factory and I come to the conclusion that it's probably not worth the trouble to try to create the persisters on demand only.
If I really run into memory problems I will invest in building an application server layer that can be shared by the enduser-processes.

Regards,
Marcel

Hi Ayende

I am facing a similar issue with my win client application. i am trying to do a build session factory for roughly 2000 odd domain objects. What I can see is the memory usage goes up by approx 135 MB which is a large footprint. So is there a way I can bring down this memory footprint or can I even think of doing a build session on dmand basis?

I'm thinking that after startup any application using any framework will have many objects to dispose of more than at other times. You could always force the GC to collect. I'm not saying that this would necessarily be a good idea to go into production with but it could give you an idea of how many objects that are actually needed are eating up memory.

Another test would be to wait a little bit and see if the GC recovers any memory (see if you footprint goes down). This could be used to determine if this would actually be a production problem for you.

Post your results back here I would be interested myself.

I tried forcing GC to collect after BuildSessionfactory but with no gain ..I had also tried serializing configuration object one time and then every time during startup only deserialize this. But this doesnt work f anybody has done this successfully please let me know..