2

We're trying to reduce the Fluent nHibernate startup overhead.

All the articles we've seen on this subject (including this one) make the following two suggestions:

  1. Persist the configuration on the first run and restore that subsequently, instead of re-creating it.
  2. Make sure the ISessionFactory is created only once per session of the app.

We've done both of these, and the Fluent nHibernate startup time to create the session factory is now around 550ms on a dual-proc 2.8Ghz 64 bit Windows 7 system, with a SQLite backend. There are only four entities at present, with about six properties each on average.

This is still way too high. We'd like to reduce this time to 20ms or less (so that even on slow systems it will be less than 100ms). Is there any likelihood of us being able to do this?

Any insight into what Fluent nHibernate is doing during startup that takes so long will also help.

Community
  • 1
  • 1
bright
  • 4,700
  • 1
  • 34
  • 59
  • 1
    "Any insight into what Fluent nHibernate is doing during startup that takes so long will also help" - have you looked at the log file? NH+F does a lot of logging and you can see where the time is spent the most – Igor Brejc Apr 17 '11 at 11:33
  • 1
    What's your scenario? If this only happens once (which is the normal situation) then is 1/2 a second a big deal? You shouldn't be creating the ISessionFactory more than once per app lifetime under most scenarios. – UpTheCreek Apr 17 '11 at 13:52
  • @UpTheCreek: Yes, as explained this happens only once. It is very important because it affects app responsiveness. In addition this is a very fast system, and running on a slower system will be worse, and probably a lot worse. We know how to present the illusion of responsiveness, by having the rest of the app start up in parallel, but this half second is a real pain in the ass (sorry, but that's the only way to communicate the angst here.) – bright Apr 17 '11 at 14:09
  • I'm that case I think you might be asking too much of it. Maybe you can make ISessionFactory creation marginally faster by dropping automapping (if you are using that), or dropping fluent altogether and using standard xml mapping files. However, if you have a requirement for lightning fast startup then perhaps an ORM is not an appropriate choice. – UpTheCreek Apr 17 '11 at 15:04
  • @UpTheCreek: 550ms on a machine of this size is really an eternity, which is why we're scratching our heads wondering what NH+F is doing. Hopefully a good samaritan will put us out of this particular misery. We're going to look at the log files that @IgorBrejc suggested as well. – bright Apr 17 '11 at 15:51

1 Answers1

0

You could use a WCF service that manages your SessionFactory. Since this is independent of your application the start-up time would not be affected at all by the creation of your SessionFactory. Of course this does bring a number of other complexities (lazy loading for one) to the equation but it does solve your problem of startup time since the service would already be running when you start up your app.

Cole W
  • 15,123
  • 6
  • 51
  • 85
  • That's a reasonable idea if all else fails. However it it really quite complex - another binary, installing a service etc. We're targetting an xcopy-deploy project that can also be run from a flash drive. – bright Apr 17 '11 at 15:49