| Groups | Blog | Home |
dotnet performance : Reflection.Cache
I know that the Code I’ve written will sound silly to some of you, and maybe
it is. I am planning to change it. ANYWAY ;-) I do create and Initialize *a lot* (+-5000) of object (that not-quite incidentally, are also different classes). To do that I use extensively reflection .GetMembers() GetMethod() GetFields().GetValue() et etc etc Yes it IS slow, yes I am gona use “normal†virtual properties. But how is it possible that after this procedure and GC.Collect()’ing everything there is still 200.000 object still present in the heap ? (MemberInfo, PropertiesInfo, ClearCacheHanlder, and more, with 150 MB of process ram used). After doing a bit of research with the .Net memory profiler (excellent tool !) and Lutz Roeder’s .Net reflector (amazing tool :-) it appears to me that there is a private Reflection.Cache object that does not provide any way to Flush its “became useless†content. Is it normal that the Reflection library is so careless about its memory consumption? Can it be tweaked in some way that does not involve recompiling Reflection to made those private lullabies public ?
Yes, you are mostly right, and thank you for your answer. The usage of
reflection to initialize once, one object (singleton of its class) is overkill (especially for thousand of them :-). Reflection is too slow and probably not done for such purpose... I have already fixed that. To clear things up: no those classes are not Emit’ed. They are pure C# files. You can easily understand the purpose like this: Classes and nested classes are constructed just like any (think XML) *data* representation. They could as well be constructed with reflection.Emit, but why bother ? the compiler handles the task much better, and to get to the point: at code design time. You then have nice strongly typed data/object, even presented/browsable/commented by intellisense (just one example). The idea is not really mine, because other designable class-instance breed already provide this feature (namely Component(or Control) implementation (win/web form etc etc). I just apply the theory to its full extend ;-) Digging docs and so I found that an assembly “<=1.1†support up to16 million classes. Some site like http://blogs.msdn.com/joelpob/ provide really nice “insider†information… An application (many assembly ?) with more then 10000 designable component is not far-fetch to my point of view. I hope that I am not wrong, and that ..Net won’t give-up on me :-) Generics of 2.0 partly solve this problem of strong typing similar functionalities, but it also implies building new classes at run-time (even behind the scene)… But more to the point of this performance newsgroup, I can still not believe that any cache whatsoever can eats up so much ram without further notice. There ARE actually links between the GC class and Reflection.Cache.ClearCacheHandler private thing (so said disassembler). But all I know (or think I know ;-) is that asp_net iis process still gets recycle (60% of physical ram limit) without trying first to flush those 130 useless-and-just-made-my-os-swap-a-little-more MB. A process gone is a deadly performance issue ;-) but maybe I am not on the good newsgroup... [quoted text, click to view] "Philipp Schumann" wrote:
> I have no insight into the inner workings of Reflection, and I do agree that > if Reflection info objects are cached such behaviour SHOULD be documented, > if only to prevent others from creating their own caching hashtables to > store MemberInfos and stuff (as I did at some point because I figured the > slow thing about Reflection might just be the reflection bit - reading and > parsing the metadata - rather than the dynamic invocation). > > However -- > > am I correct in understanding that the ~5000 objects are all of different > classes? I have to assume they are generated dynamically using Reflection > Emit or something. I'm not sure Reflection, or indeed the .NET Framework, > was ever designed with applications of such a scale in mind, regardless of > whether it is an architecturally reasonable thing to do so or not. That > said, because you can safely assume that: > > - in most cases, the infos read by reflection will not change during the > lifetime of your application once an Assembly is loaded into your app domain > - most assemblies will have reasonably small numbers of types and members > > I wouldn't be surprised if the cache is indeed designed not to be cleared at > all - considering the two points above, why would you want to? So, while I > have no insight into the API design of Reflection, I suggest this behaviour > might just be by design... > > "Questionner" <Questionner@discussions.microsoft.com> schrieb im Newsbeitrag > news:60505443-593E-44C4-B322-17CD600C8B0E@microsoft.com... > >I know that the Code I've written will sound silly to some of you, and > >maybe > > it is. I am planning to change it. > > > > ANYWAY ;-) I do create and Initialize *a lot* (+-5000) of object (that > > not-quite incidentally, are also different classes). To do that I use > > extensively reflection .GetMembers() GetMethod() GetFields().GetValue() > > et > > etc etc > > > > Yes it IS slow, yes I am gona use "normal" virtual properties. But how is > > it > > possible that after this procedure and GC.Collect()'ing everything there > > is > > still 200.000 object still present in the heap ? (MemberInfo, > > PropertiesInfo, > > ClearCacheHanlder, and more, with 150 MB of process ram used). > > > > After doing a bit of research with the .Net memory profiler (excellent > > tool > > !) and Lutz Roeder's .Net reflector (amazing tool :-) it appears to me > > that > > there is a private Reflection.Cache object that does not provide any way > > to > > Flush its "became useless" content. > > > > Is it normal that the Reflection library is so careless about its memory > > consumption? Can it be tweaked in some way that does not involve > > recompiling > > Reflection to made those private lullabies public ? > > I am wrong about the whole thing ? ;-) > >
I have no insight into the inner workings of Reflection, and I do agree that
if Reflection info objects are cached such behaviour SHOULD be documented, if only to prevent others from creating their own caching hashtables to store MemberInfos and stuff (as I did at some point because I figured the slow thing about Reflection might just be the reflection bit - reading and parsing the metadata - rather than the dynamic invocation). However -- am I correct in understanding that the ~5000 objects are all of different classes? I have to assume they are generated dynamically using Reflection Emit or something. I'm not sure Reflection, or indeed the .NET Framework, was ever designed with applications of such a scale in mind, regardless of whether it is an architecturally reasonable thing to do so or not. That said, because you can safely assume that: - in most cases, the infos read by reflection will not change during the lifetime of your application once an Assembly is loaded into your app domain - most assemblies will have reasonably small numbers of types and members I wouldn't be surprised if the cache is indeed designed not to be cleared at all - considering the two points above, why would you want to? So, while I have no insight into the API design of Reflection, I suggest this behaviour might just be by design... "Questionner" <Questionner@discussions.microsoft.com> schrieb im Newsbeitrag news:60505443-593E-44C4-B322-17CD600C8B0E@microsoft.com... [quoted text, click to view] >I know that the Code I've written will sound silly to some of you, and >maybe > it is. I am planning to change it. > > ANYWAY ;-) I do create and Initialize *a lot* (+-5000) of object (that > not-quite incidentally, are also different classes). To do that I use > extensively reflection .GetMembers() GetMethod() GetFields().GetValue() > et > etc etc > > Yes it IS slow, yes I am gona use "normal" virtual properties. But how is > it > possible that after this procedure and GC.Collect()'ing everything there > is > still 200.000 object still present in the heap ? (MemberInfo, > PropertiesInfo, > ClearCacheHanlder, and more, with 150 MB of process ram used). > > After doing a bit of research with the .Net memory profiler (excellent > tool > !) and Lutz Roeder's .Net reflector (amazing tool :-) it appears to me > that > there is a private Reflection.Cache object that does not provide any way > to > Flush its "became useless" content. > > Is it normal that the Reflection library is so careless about its memory > consumption? Can it be tweaked in some way that does not involve > recompiling > Reflection to made those private lullabies public ? > I am wrong about the whole thing ? ;-)
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |