Well the speed differences are certainly real. But clearly coding can make some difference too. And a big factor in anything networked is the "glue" protocol involved.

We have a 3rd party product we use that processes dirty postal address data with its own algorithms and a large postal database. Originally this was front-ended by a service written in VB.Net 2003 that provided client systems with a Web Service interface.

This was balky, slow, and lost transactions at times.

So I ripped it out and replaced it with a service written in VB6 that used a simple protocol over TCP. We saw almost a 12 times improvement in performance and no longer lost any transactions.

I think a good part of this was due to XML generation, parsing, and transport overhead. Another chunk might have been the interop needed to get to the 3rd party product's standard DLL interface. For that matter the VB.Net code may have been crappy: it clearly recopied large data blobs that didn't need recopying and I'm pretty sure it was repeatly translating large blocks from bytes to Unicode characters and back. Of course people do that in VB6 a lot too because they don't know when not to use Strings. Then there is the overhead of everything passing through IIS.

It couldn't all be network transport costs though because memory and CPU use on the server went way down.