I made a test with 1000 items, using our simulation server, locally. The time to read these 1000 items (on subsequent reads) is around 1 second. Doing this over network, and with server that may (or may not) have lower performance, is therefore likely to give a time that is considerably higher than 1 second.
I understand that you are looking for better performance, so I plan to do more tests in order to see whether this can be improved further, in a hope that if they help with my test, they may be beneficial to your situation, too.
I know that your network is fast; have you, however, made a test where the OPC server and OPC client are both on the same machine, so that we have trusted information about whether the bottleneck has to do with the communication, or something else (performance of the client or the server)?
Can you please tell me which OPC server are you connecting to? I find it hard to believe that it does not support subscriptions. It would be very unusual (and clearly not compliant with OPC); in addition, I think that the server must at least "pretend" that it does support them, because we are calling functions that are related to subscriptions, and if they were failing, you would be getting error messages.
As you know, repeated reads are inefficient, so I am trying to figure out why we cannot go "the right way". The expected sustained throughput with subscriptions (locally) can be 4000 changes per second or more.
Instantiating unnecessary objects inside the loop is not particularly good, but I do not think it has a substantial influence in this case. I still suggest that you move the creation of EasyDAClient object outside the loop. I suppose that the times you are giving are just for the read method call (these other things should not be significant anyway, but should be ruled out in the timing nevertheless).