I'm working on an application that does lots of encryption and decryption in-application and this is probably the number-one bottleneck, so I've been spending some time making performance tweaks to it. A lot of this has involved simply caching things in memory (I realize there is something of a security tradeoff in doing that), but I noticed during profiling that Dispose() was a fair amount of the time doing decryption (I believe for .NET cryptography stuff it zeroes over everything so this makes sense). So I came up with this idea:
Have a "dispose pool." Instead of using blocks, create objects, use them, return the result, and add them to the dispose pool in the finally block. Internally, the dispose pool uses a queue and a timer and every time the timer fires it dequeues the objects and disposes them.
I tried implementing this and it seems to work and improve performance, but then again, profiling it locally is not a really realistic use case. Is this sound? Am I likely to run into runaway performance issues I'm not currently thinking about?
I suppose I should add that this is an ASP.NET MVC application so everything revolves around requests.
Best Answer
You might take a look at Microsoft's ScheduledDisposable. I've never used it, but it looks as though it will queue your objects for disposal on a separate thread.
But if a pool is what you're looking for, I think this will work:
Note the factory itself is disposable. I certainly would be reluctant to use this for finalizable objects however.