Once slow code has been identified, the next step is to address those issues. One popular technique for addressing how data is passed between the application and the Web service is to carefully monitor and optimize the amount of data transmitted in each SOAP call.

In this circumstance, one change that can be considered is whether the code should be “chatty” or “chunky.” As the names imply, chatty calls are those that occur often and pass little data, while chunky calls occur less frequently but do more work when they do occur.

While at first glance it might appear that large calls to the service are more efficient, that’s not necessarily true. A chatty interface passing less complex data more often may turn out to be less computationally expensive because its marshalling isn’t as complex.

How to determine whether or not one should be using chatty or chunky calls to the service? There’s no easy way that applies to all circumstances; it depends on the amount of data and frequency of calls. The best thing to do is to prototype both the type of interface and the performance profile. By investing a little time early in the development phase, one can ensure that the right performance choice has been made and not have to go back and make substantial changes after there is a working application.

That’s not to say that one might not have to go back and make adjustments to the calls once the application is done. For example, it may be found that in certain Web services features, chunky calls are more efficient because of the overall volume of calls. But prototyping the data and calls ahead of time gives a better ability to determine the optimum amount of data to exchange with the Web services in individual transactions.

Another common problem is that certain .NET services can be computationally expensive. At first glance it may appear that we have little control over what the .NET Framework does. However, the framework is rich in features, and there are often multiple ways of obtaining the services that are in need. Alternatively, the framework calls that are being used may be doing more work than actually needed. We won’t know any of this unless we have complete profiling information on child behavior from our own methods.