You could write it to a compressed ramdisk if it's really ram- sensitive, I can share sourcecode for one, but then you'll have to do some memory management, too. It uses the buddy algorithm, code in C# with p/invoke to Win32/HeapAlloc http://msdn.microsoft.com/en-us/library/aa366597(VS.85).aspx and unsafe C#. Tests come with it, SharpZipLib for compression (not 100% complete, but I can help you work out the kinks). You could possibly serialize the configuration wither manually or with the binary serializer, to store in on the ramdisk with retreive on demand.
You could also try to run Mono's Linker on your project->(ref) NHibernate to remove the code which you are not using. I'm not 100% sure how much reflection is going on in NHibernate's internals, but if the dynamic bindings aren't too bad, this could be a very realistic option. http://www.mono-project.com/Linker -- part of the memory requirement will be the loading of the rather big code of NHibernate and another part the configuration data it has; the linker would remove some of the loaded code, but probably not do so much for the dynamic/configuration data. On May 8, 12:56 pm, codegoblin <[email protected]> wrote: > Hi Fabio > I hope I am not misrepresenting myself . I am not trying to find any > issue with Nhibernate, I can already see the benefits of using the > same .Its like preaching the quire about the gains to use Nhibernate > and prebuilding factories. Its just that I am trying real hard to keep > NH inside my app . Which would not be the case if I cannot bring my > memory footprint down. Its just a wiered scenario where I am trying to > make a case with management. Also I do appreciate all the pointers you > have shared so far with me. > 1. Today I tried one more option of serializing configuration in > different appdomain and deserializing it which is showing me 10MB gain > but my issue is this is happening in NH 2.1 where my memory footprint > has already gone up. I wish serialization was an option with NH1.2.1 > > Thanks > > On May 7, 9:34 pm, Fabio Maulo <[email protected]> wrote: > > > performance mean you must pay something and in general the memory is what > > you pay.For example all loggers are static, all default types are static, > > all info inside mappings are compiled at startup and if you have a > > live-instance of nh-configuration all meta-data stay alive (the > > configuration is statefull). > > If you can find some memory leak let us know in JIRA. > > > 2009/5/7 codegoblin <[email protected]> > > > > Heres the reason why > > > I performed a small test using console application and using all our > > > domain object . I created a application that does "addassembly" and > > > then does build session factory > > > > Memory footprint of application using NH1.2.1 with 1700 entities is > > > approx 144 MB > > > Memory footprint of application using NH 2.1 (Audi RS6) is 172 MB > > > > Also to note a important thing here is, this is additional 170MB as > > > opposed to my application without NHibernate. I am really surprised > > > of the fact that no one else is facing similar isssue. Also after > > > performing this test with NH2.1 I did take a memory dump after I had > > > buildsessionfacoty and closed it followed by dispose and GC.Collect. I > > > was hoping not to see any NH objects and my memory to go back to the > > > size of console application along with the footprint of assemblies > > > loaded. But to my surprise it still had objects of type Nhibernate as > > > residents of Gen2 of GC pinned to Nhibernate.Impl.SessionImpl > > > > 0:000> !dumpgen 2 -stat > > > "I have cut the contents to fit them here > > > 1 36 > > > log4net.Repository.Hierarchy.RootLogger > > > 45 540 log4net.Util.ReaderWriterLock > > > 44 1408 log4net.Core.LogImpl > > > 44 1408 > > > log4net.Repository.LoggerRepositoryConfigurationChangedEventHandler > > > 1 12 NHibernate.Cache.NoCacheProvider > > > 1 12 NHibernate.Cfg.DefaultNamingStrategy > > > 1 152 NHibernate.Event.EventListeners > > > 3419 41028 Iesi.Collections.Generic.HashedSet`1 > > > [[System.String, mscorlib]] > > > 1 12 > > > NHibernate.Bytecode.Lightweight.BytecodeProviderImpl > > > 1 52 > > > System.Collections.Generic.Dictionary`2 > > > [[NHibernate.Event.ListenerType, NHibernate],[System.Type, mscorlib]] > > > 1 12 > > > NHibernate.Util.UnmodifiableDictionary`2 > > > [[NHibernate.Event.ListenerType, NHibernate],[System.Type, mscorlib]] > > > 1 12 > > > System.Collections.Generic.ObjectEqualityComparer`1 > > > [[NHibernate.Event.ListenerType, NHibernate]] > > > 1 12 > > > NHibernate.Event.Default.DefaultLoadEventListener > > > 1 12 > > > NHibernate.Event.Default.DefaultSaveOrUpdateEventListener > > > > Also I can see few object like one below with no refs but pinned > > > strongly to Sessionfactory . > > > Statistics: > > > MT Count TotalSize Class Name > > > 07ae276c 121779 1948464 NHibernate.SqlCommand.Parameter > > > > 0:000> !refs 0eb13c60 > > > Objects referenced by 0eb13c60 (NHibernate.SqlCommand.Parameter): > > > NONE > > > > Objects referencing 0eb13c60 (NHibernate.SqlCommand.Parameter): > > > NONE > > > > and below you can see this same object has GCroot to > > > NHibernate.Impl.SessionFactoryImpl > > > > 0:000> !gcroot 0eb13c60 > > > Note: Roots found on stacks may be false positives. Run "!help gcroot" > > > for > > > more info. > > > Scan Thread 0 OSTHread 12a0 > > > ESP:12f408:Root:05bc6860(NHibernate.Impl.SessionFactoryImpl)-> > > > 05bce6c8(System.Collections.Generic.Dictionary`2[[System.String, > > > mscorlib],[NHibernate.Persister.Entity.IEntityPersister, NHibernate]])- > > > > 099f5aa0(System.Collections.Generic.Dictionary`2+Entry[[System.String, > > > mscorlib],[NHibernate.Persister.Entity.IEntityPersister, NHibernate]] > > > [])-> > > > 0ab74d20(NHibernate.Persister.Entity.SingleTableEntityPersister)-> > > > 0ab7502c(System.Collections.Generic.Dictionary`2[[System.String, > > > mscorlib],[NHibernate.Loader.Entity.IUniqueEntityLoader, NHibernate]])- > > > > 0eb0de5c(System.Collections.Generic.Dictionary`2+Entry[[System.String, > > > mscorlib],[NHibernate.Loader.Entity.IUniqueEntityLoader, NHibernate]] > > > [])-> > > > 0eb139c4(NHibernate.Loader.Entity.CascadeEntityLoader)-> > > > 0eb1570c(NHibernate.SqlCommand.SqlString)-> > > > 0eb156dc(System.Object[])-> > > > 0eb13c60(NHibernate.SqlCommand.Parameter) > > > Scan Thread 2 OSTHread 1180 > > > Scan Thread 7 OSTHread 1688 > > > > I am digging into the code to find more but I can smell some leak > > > here . Please let me know if my deductions are incorrect ? > > > > On May 5, 7:30 pm, Fabio Maulo <[email protected]> wrote: > > > > About NH1.2.1 modification....You have the last AUDI RS6 in the garage > > > and > > > > you have the key in yours hands. > > > > Why you want "adjust" the LANCIA Delta GTO ? > > > > > 2009/5/4 codegoblin <[email protected]> > > > > > > Fabio > > > > > > I totally agree wiith you that serialization wont help me in reducing > > > > > memory. All I am trying for is following > > > > > > Currently NHibernate loads all assemblies when the code does > > > > > config.addassembly("assemblyname") . It goes thru all the assemblies > > > > > and starts validating hbm.xml file so on so forth . But the fact > > > > > remains that those assemblies stay lingering around till the > > > > > application life time which adds to the memory footprint. All I was > > > > > trying to do was to do addassembly and build config object in > > > > > different APPDOMAIN and unload it once I have passed the config object > > > > > back to default config object. This would help us reduce the footprint > > > > > of loaded assemblies which are not required anymore. But when I try to > > > > > getdata /setdata it gives me serialization error for "config" > > > > > object ...hence serialization > > > > > > On May 4, 6:10 pm, Fabio Maulo <[email protected]> wrote: > > > > > > 2009/5/4 codegoblin <[email protected]> > > > > > > > > In that case I will be touching the source code of NHibernate and > > > what > > > > > > > would be the things required to do if we change NH source code > > > > > > > > 1. I would have release NH 1.2.1 with the patch ? > > > > > > > No. > > > > > > > > 2. Does that make my app vulnerable to be part of open source as > > > well > > > > > > > according to LGPL? > > > > > > > No, if you make the patch public or the project fork public. > > > > > > > Btw, the serialization is not the solution for memory size. > > > > > > > -- > > > > > > Fabio Maulo > > > > > -- > > > > Fabio Maulo > > > -- > > Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
