The importance of measuring performance changes is a topic that has been covered by others smarter and more experienced than me, but I have a recent simple tale.
I’ve simplified the code quite a bit in order to demonstrate the issue. Suppose I have a wrapper around an image (it has many more attributes):
1: class Picture
3: Image _image;
4: string _path;
6: public Image Photo
10: if (_image==null && !string.IsNullOrEmpty(_path))
12: _image = Bitmap.FromFile(_path);
14: return _image;
I had this and a view that loading about 2,700 of these into a customized ListView control at program startup. On a cold start (where none of the pictures were in the disk’s cache), it would take 27 seconds. Unacceptable.
What to do?
My first thought was to load the pictures asynchronously. I wrapped Bitmap.FromFile() into a function and called it asynchronously. When it was done, it fired an event that percolated up to the top.
Well, I spent about 30 minutes implementing that and ran it–horrible. The list showed up immediately, but it was unusable. The problem? Dumping 2,700 items into the ThreadPool queue is a problem. It doesn’t create 2,700 threads, but it causes enough problems to not be a viable option.
Asynchronicity is still the answer, though. But it’s at a different level. Instead of loading the individual images asynchronously, I skipped loading the images when creating the list control and instead launched a thread to load all the images and update them when done. The list loads in under a second, and the pictures show up little by little after that.
Measure, measure, measure. And pay attention.
Technorati Tags: code,asynchronous program model,c#