>>It's not that. It's the bloat in the SOAP package and the data travelling over the wire. Encoding an XML string easily doubles its size (depending on the data density vs fields)... For Web Services that's a significant hit both in terms of perf (encoding/decoding) as well as the bandwidth requirements...
>
>You're right, of course, (although I don't know much about the encoding/decoding thing) but I wonder how bad it really is. We have one DataSet that has 75 tables ... not every table always has data in it and none of the tables have more than a few rows each ... and yet, it doesn't really take that long to come across the wire. It's a totally acceptable time span (don't ask me what it is ... I haven't done the benchmarks, it's not my area of the application). Yeah, it would probably fly if we passed a DataSet instead of XML, but that's not my point.

<g>

You might want to do a size comparison sometimes, just for kicks since if you have 75 tables that stuff will REALLY add up. See if you encode XML into an XML String all the open and close tags because 3 characters each, plus any special characters like quotes ("e; of which there are lots in the schema). Now think about the schema that usually goes with a dataset and all those tags.

I'm not usually THAT concerned with speed either, but in this case - because DataSet as XML is generally pretty bloated already - it makes a significant difference even with relatively small amounts of data over a reasonably fast Internet connection.

Talking about worrying too much about speed: I was looking at Dino Esposito's Web log the other day and there were people whining about the overhead of using HttpContext.Current vs. passing the current context to the method. Geez - with the above stuff these guys woulda had a heart attack. This is what you get when you deal with C++ programmer <g>...