On Fri, 19 Dec 2008, Daniel Stenberg wrote:
> As I recall things libssh2 is not up to par with other implementations
> speed-wise and I might just be digging into this soon.
One thing that immediately struck me when I did some callgrind and other test
runs:
It uses malloc beyond crazy. In my test sample I do 60 SFTP uploads (doing
each upload with very many small sftp_write calls) using 4 parallell
connections, and I got roughly 60,000 calls to malloc (and of course just as
many to free). And you know what? The top-10 allocations done are distributed
like this:
number of calls, size of the malloc
17003 malloc(32)
8511 malloc(63)
8393 malloc(24)
3860 malloc(100)
1977 malloc(66)
1977 malloc(57)
1346 malloc(884)
1346 malloc(848)
1346 malloc(839)
1328 malloc(84)
.. quite obviously there are vast amounts of very small sizes allocated.
Admittedly this is partly because my test app is torturing the lib by sending
the files in very small chunks at a time.
The maximum total amount of memory at any given time was still not very large.
I did this using libcurl and the max stopped at 330K and then of course
libcurl used a fair share of that amount too - but only did a very small
fraction of the mallocs as the total stopped at 60254.
I'm convinced we can avoid a large number of the mallocs by simply allocating
the buffer in the handle or session struct instead.
--
/ daniel.haxx.se
------------------------------------------------------------------------------
_______________________________________________
libssh2-devel mailing list
libssh2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libssh2-devel
