dave wanta <[EMAIL PROTECTED]> wrote: > That would be a good work-around. But, I don't have write access (gotta love > all of these constraints. ;-) )
The solution I would use in this scenario is a class I've developed for a similar purpose. As you may be aware, large objects (i.e. greater than 85000 bytes, currently) get allocated on the large object heap (LOH). The LOH doesn't get scanned until a Gen2 GC occurs, which means that such large objects are expensive to collect. As a result, a pooling strategy usually pays off to keep GC% time low. To make pooled arrays useful, the clients can't expect exactly sized arrays - so instead they work with slices. The class hides much of the distinction and complexity. I recommend that you use a similar approach. Work with bigger arrays than you need, but keep a separate "count" which indicates how much of the array you're currently actually using. Use a geometric series of array lengths (doubling each time is fine) to ensure amortized linear time for allocations and copies. -- Barry -- http://barrkel.blogspot.com/ =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
