It looks like the speed of executing T-SQL is dependent on the latency of the network connection against the server. I assumed that if SQL Server has nothing to report back to the client about, it will just execute away until it is done but testing shows another story.
create procedure UselessLoop @I int as declare @D datetime = getdate() while @I > 0 set @I -= 1 print datediff(millisecond, @D, getdate())
exec UselessLoop 100000
Server Milliseconds local 53 nearby 63 faraway 660
exec UselessLoop 1000000
Server Milliseconds local 546 nearby 640 faraway 6183
The tests are executed against the same server from different computers using SSMS. Local is executed from the Server, nearby is on the same local network and faraway is executed from another office 500 km away connected with 1 gigabit fiber.
There is obviously some communication going on between SQL Server and the client that directly is dependent on the number of statements executed.
I used Wireshark to look at what is transported and I can't say that I understand that much but it was a tcp.stream exchanging a total of 26 MB in 22740 packets.
How about a useless function instead?
create function dbo.UDFUselessLoop(@I int) returns int as begin declare @D datetime = getdate() while @I > 0 set @I -= 1 return datediff(millisecond, @D, getdate()) end
It executes in 406 milliseconds regardless of where it is executed from. Looks like there is no communication with the client in the loop.