 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / January 2008life-time pinning. vs Global heap
I am very sorry to bring a topic up that has been beaten with an ugly stick..... but... If I want to "fix" an byte array for the life time of a program would it be better allocating it on the unmanaged heap? Yes I know that if I am to pin the object for long periods of time, that it would be best to do it at the very initial start of the program so that it prevents some fragmentation of the managed heap. Thanks in advance for your thoughts on the matter. The word "fix" is somewhat confusing here. If you really only need to have the byte array available for the lifetime of the appDomain, you can just add the static modifier. Or, you could create a byte array property and make it readonly. --Peter Site: http://www.eggheadcafe.com UnBlog: http://petesbloggerama.blogspot.com MetaFinder: http://www.blogmetafinder.com > I am very sorry to bring a topic up that has been beaten with an ugly > stick..... but... [quoted text clipped - 7 lines] > > Thanks in advance for your thoughts on the matter. Oops, sorry for the confusion.... I am using the array in an unsafe context. (via pointers.) I do not want to continuously use the fixed(byte* ptr = myArray) statement, so that leaves pinning via GCHandle, or allocating on the unmanage heap. Thanks for the responce. > The word "fix" is somewhat confusing here. If you really only need to have > the byte array available for the lifetime of the appDomain, you can just add [quoted text clipped - 16 lines] > > > > Thanks in advance for your thoughts on the matter. With all due respect, not wanting to use the fixed statement is a very, very poor reason to keep something pinned in memory like this. Using an unmanaged buffer is only going to help if you are not going to access the memory outside of an unsafe context. In that case, you would have to marshal the memory block back to managed code (and then back to unmanaged when you are done making changes to it, as well as more than likely protect access with a lock, if concurrency is a concern). Why do you not want to use the fixed statement?  Signature- Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com > Oops, sorry for the confusion.... > I am using the array in an unsafe context. (via pointers.) [quoted text clipped - 31 lines] >> > >> > Thanks in advance for your thoughts on the matter. Reasoning: (for better or worst) The byte array is used throughout the life time of the program, and would have to be fixed -least- every 20ms for processing. The Idea is that the array would be up and out of the way from the garbage collector, because there realy isnt a point in including it in the gc process. I know the fixed statement doesnt incurr much at all for pinnning, atleast until the garbage collection cycle is triggered when the object is pinned. > With all due respect, not wanting to use the fixed statement is a very, > very poor reason to keep something pinned in memory like this. [quoted text clipped - 42 lines] > >> > > >> > Thanks in advance for your thoughts on the matter. This is the kind of situation where you really have to test it out both ways in order to see what the performance impact is (because that is the issue here, right?). Because we don't know anything about the allocation patterns of your app, it's impossible to tell how often a GC would occur, and how repeated fixed statements would be impacted versus pinning the array once. It's something you are going to have to measure, and compare for yourself. Signature- Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com > Reasoning: (for better or worst) > The byte array is used throughout the life time of the program, [quoted text clipped - 60 lines] >> >> > >> >> > Thanks in advance for your thoughts on the matter. Thanks for your thoughts on the matter. > This is the kind of situation where you really have to test it out both > ways in order to see what the performance impact is (because that is the [quoted text clipped - 70 lines] > >> >> > > >> >> > Thanks in advance for your thoughts on the matter. My personal experience is that the best bet is to: - Allocate a big byte array at the start of your program. This ends up coming out of the Large Object Heap. - Pin the array using the GC Handle. - use ArraySegment<T> to partition the big array during the lifetime of your app... -- Chris Mullins > I am very sorry to bring a topic up that has been beaten with an ugly > stick..... but... [quoted text clipped - 9 lines] > > Thanks in advance for your thoughts on the matter. Thanks Chris. I didnt know about the ArraySegment<T> :D Oh yea... and the Large Object Heap..... It has a tendency not to move objects as well. humm..... Once again thanks for the insightful answer. :) :) :) > My personal experience is that the best bet is to: > - Allocate a big byte array at the start of your program. This ends up [quoted text clipped - 19 lines] > > > > Thanks in advance for your thoughts on the matter. Don't assume that because the LOH isn't compacted today, that it won't be in the future. Be sure to pin whatever you allocate, so that you're future proof. It would suck to have a customer installed a Service Pack, and have your app break. -- Chris > Thanks Chris. > I didnt know about the ArraySegment<T> :D [quoted text clipped - 31 lines] >> > >> > Thanks in advance for your thoughts on the matter. Yes of course. I attempted to imply that the gc doesn't try very often to move large objects so the gc performance penelty for pinnin will be reduced. Thanks again. > Don't assume that because the LOH isn't compacted today, that it won't be in > the future. [quoted text clipped - 40 lines] > >> > > >> > Thanks in advance for your thoughts on the matter. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.