`read_multi_vars` in v3.0.0 is approx 10 times slower than v2.1.1

[GaffaSnobb]

In my setup I periodically read a bunch of values from an S7-300 using the read_multi_vars function. As the title states, in v3.0.0 read_multi_vars is approximately 10 times slower than read_multi_vars in v2.1.1.

[gijzelaerr]

interesting! Did you try the latest master version?

$ pip install git+https://github.com/gijzelaerr/python-snap7.git@master

please let me know if there is any difference.

[gijzelaerr]

Ran a reproduction against the server emulator bundled in python-snap7 (pure Python, no real PLC). Localhost only — I wanted to isolate the library's contribution from network RTT. 200 iterations per pattern.

Per-call times on localhost (ms)

Pattern	v2.1.0 (C lib)	v3.0.0	master
1 var	1.28	0.08	0.04
5 contiguous	1.28	0.21	0.07
10 contiguous	1.29	0.36	0.08
10 scattered	1.29	0.35	0.14
20 contiguous	1.29	0.70	0.11
20 scattered	1.29	0.71	0.22

These numbers do NOT reproduce the 10× slowdown you report — on localhost v3.0.0 is actually faster than v2.1.0. That's because v2.1.0 has a constant ~1.28 ms ctypes/C-lib floor that dwarfs v3's per-call cost at zero RTT.

What the bench might show is the mechanism behind what you're hitting:

• v2.1.0 is flat at ~1.28 ms regardless of N. The native Cli_ReadMultiVars sends one PDU per call.
• v3.0.0 scales linearly with N — roughly 0.08 + 0.03 × N ms. Internally it calls read_area once per variable, which means N separate TCP round-trips per read_multi_vars call.
• master is nearly flat: the multi-var optimizer (Add multi-variable read optimizer #641) merges adjacent byte ranges and packs up to ~20 4-byte reads into a single PDU. One round-trip per batch.

There's a second master-side fix that should help you too: #677 enables TCP_NODELAY and SO_KEEPALIVE on all sockets. v3.0.0 ships without either. Nagle's algorithm on a small-PDU write will delay the kernel by ~40 ms waiting for more data — on top of the N-round-trip cost above. With TCP_NODELAY each small S7 request goes out immediately. That alone can be a large fraction of the regression on real networks even independent of the optimizer.

Could you verify master against your S7-300?

pip install --upgrade "python-snap7 @ git+https://github.com/gijzelaerr/python-snap7.git@master"

If you can share your v2.1.1 vs master timings on whatever pattern you actually hit (roughly how many vars per call, data types) we can confirm the fix lands on real hardware and close this.

[GaffaSnobb]

I havent forgotten about this issue! Thing is I haven't had the opportunity yet to test what you're suggesting because the PLC is being used for performance-sensitive work. Will test as soon as I have the chance.