There is currently a call to CloudBlockBlob::Existshere in BlobStorageProvider::ReadStateAsync. This results in a full request/response out to the storage service API just to get a thumbs up that the blob exists. Then, assuming it does, there's a call to CloudBlockBlob::DownloadToStreamAsync. You can eliminate this extra overhead simply by being tolerant to the possibility of an exception being thrown from the DownloadToStreamAsync call and checking the exception details to see if the root cause is the container or blob not existing.
Assuming the blob is going to exist the majority of the time, this is a really cheap and easy optimization to make. Also, let's not forget that you are actually being billed for each and every transaction against a Azure Storage account, so if you can cut that extra call here that's 50% money saved on each invocation of the method. :smile:
There is currently a call to
CloudBlockBlob::Existshere inBlobStorageProvider::ReadStateAsync. This results in a full request/response out to the storage service API just to get a thumbs up that the blob exists. Then, assuming it does, there's a call toCloudBlockBlob::DownloadToStreamAsync. You can eliminate this extra overhead simply by being tolerant to the possibility of an exception being thrown from theDownloadToStreamAsynccall and checking the exception details to see if the root cause is the container or blob not existing.Assuming the blob is going to exist the majority of the time, this is a really cheap and easy optimization to make. Also, let's not forget that you are actually being billed for each and every transaction against a Azure Storage account, so if you can cut that extra call here that's 50% money saved on each invocation of the method. :smile: