identical problem here - extremely slow when coding remotely.
windows appears to send hundreds if not thousands of tiny payload packets (150 bytes vs 1500 bytes TCP spec allows), which hikes up overhead.
discovered that during the resulting prolonged chatty idiocy that ANY lost packet would force the whole conversation to restart (vs just resending the lost tiny packet(s)), we changed the openvpn tunnel protocol from the recommended UDP to TCP, which helped but not much as we'd hoped.
this does not appear to be a slickedit problem at all, but this windows problem severely affects all remote work, particularly regarding file operations (open directory, list contents, get/put files).
of course micro$oft offers another product to fix its self-made idiocy, something called branchcache. of course since we only use ms stuff we can't otherwise escape, we'll never use this, no matter what, and would build dozens of servers and hire extra help, before we invested anymore in anything special, especially to solve self-invented problems. as always, the real culprit is windows.
so this is part venting and part warning. if you're planning to do remote coding on large codebases (hundreds or thousands of files, multiple projects), think again. local LAN 'test' server is the only feasible option.