Using the IStream interface improves performance when large amounts of data must be retrieved, but results in a large amount of overhead for smaller properties. As a general rule, use IStream only for properties greater than 16K in size.
Note This size limit exists because the RPC buffer has a maximum size. The maximum size of the buffer varies according to service provider.
Some providers, including the Microsoft Exchange Server information store, have the ability to batch IStream interface operations into calls to the IMAPIProp::GetProps and IMAPIProp::SetProps methods. If you must write many small amounts of data to a property using the IStream interface, these write operations are first held by the information store provider at the client. When you call the SaveChanges method, the provider writes them to the server with a GetProps call if they are small enough. However, this optimization still incurs more overhead than if the client itself uses GetProps and SetProps.
Small writes to a stream may also cause excessive transaction logging. If you write data to a stream and then call the SaveChanges method, the changes are committed. To ensure data integrity, each SaveChanges operation creates an entry in the transaction log. Additional write operations and SaveChanges calls create more logs. As a result, a write of less than 1K can generate more than 10K of logging information.
A Microsoft Exchange Client application uses only the IStream interface to read and write the body of a message. Even to write the word “Hello,” the IStream interface creates a stream and then closes the stream to send just eight bytes of information. This causes much more overhead than using the GetProps and SetProps methods.
Performance is noticeably improved when the client application is rewritten to follow these guidelines:
Most messages are below the maximum size retrievable by a single GetProps call. In the default case, CPU cycles and RPCs are saved bycalling GetProps or SetProps as a general rule rather than using IStream.