Closed TinoDidriksen closed 4 years ago
Why a vector of char’s?
100 KiB on the stack is generally a bad idea - stack space is limited. vector<char>
or string
makes it dynamic, but self-cleaning. It's vastly cleaner than using new[]
+ delete[]
, but same performance.
Thanks for the contribution, @TinoDidriksen! I'll let @chcg make the final call, as he's the real maintainer nowadays 👍
@TinoDidriksen Thanks for your investigation on this. Some similar topic seems to be https://libssh2-devel.cool.haxx.narkive.com/liOfI7ng/how-to-increase-performance-of-libssh2-sftp-read-write, also for libssh2 and not the libssh like used by NppFTP. See https://git.libssh.org/projects/libssh.git/tree/src/sftp.c?h=stable-0.9#n56
/* Buffer size maximum is 256M */
#define SFTP_PACKET_SIZE_MAX 0x10000000
#define SFTP_BUFFER_SIZE_MAX 16384
So I think a natural choice would be a multiple of 16KB (96 or 128).
See https://api.libssh.org/master/libssh_tutor_sftp.html at:
Reading a file from the remote computer
The nice thing with reading a file over the network through SFTP is that it can be done both in a synchronous way or an asynchronous way. If you read the file asynchronously, your program can do something else while it waits for the results to come.
Synchronous read is done with sftp_read().
Files are normally transferred in chunks. A good chunk size is 16 KB. The following example transfers the remote file "/etc/profile" in 16 KB chunks. For each chunk we request, sftp_read blocks till the data has been received:
Ah, I didn't dig into libssh. Change done, with 128 KiB.
See https://github.com/ashkulz/NppFTP/issues/90
I tested various buffer sizes. The current 4 KiB is abysmally slow. Going above 100 KiB did not make any difference in my tests.
Disabling the UI update did not make any difference. It is the buffer size that causes it, not the resulting UI updates.
Edit: While 100 KiB makes it tolerable, it's still much slower than other clients. On the 500 KiB file, buffer size 100 KiB downloads it in 3 seconds instead of 11 seconds. Larger buffer sizes do not make it any faster, even if set larger than the file. Other clients download the same file in <0.1 seconds. But this at least removes 1 order of magnitude difference.