When using SOCKS4/SOCKS5 or HTTP CONNECT proxies, the only difference between a scenario with a proxy and without it is during the
Connect method. Once a connection is successfully established, all the communication with the IMAP server goes through a TCP socket, and from the client's point-of-view, it's 100% same for both proxied and proxy-less connections. The only difference is the target endpoint of the TCP socket. In both scenarios, the
Imap object is behaving identically once the
Connect method has finished successfully.
Additionally, unlike HTTP proxies, HTTP CONNECT itself does not perform anything to speed up things - it simply establishes a connection and forwards data packets between the IMAP server and IMAP client, without any processing at all, and without any kind of caching. HTTP CONNECT proxies don't even understand the IMAP protocol, it's all just raw data to them.
This means that if all things were equal, HTTP CONNECT proxies should be slightly slower than direct connections (because of the overhead of forwarding data packets).
It also means that the observed speedup/slowdown is almost certainly not caused by the client, but by something else - for example, when not using a proxy, your firewall or router might be doing some kind of bandwidth throttling, while proxied connections might have a higher priority. Or proxied connection may simply be using a faster network to access the IMAP server. There are dozens of possible causes, but unfortunately, without any knowledge of your network and proxy setup, we can't determine the actual cause.
Please consult your network administrator - the huge difference in observed response time is certainly unusual.
Of course, make sure you are able to consistently reproduce these results to rule out other explanations - for example, it's quite common for a search command to take substantially less time when it's issued a second time because the IMAP server already has parts of the search process cached, or because it has created or optimized it's index.