sitter created this revision. sitter added reviewers: ngraham, cfeck. Herald added projects: Dolphin, Frameworks. Herald added subscribers: kfm-devel, kde-frameworks-devel. sitter requested review of this revision.
REVISION SUMMARY see https://bugs.kde.org/show_bug.cgi?id=291835#c57 for background - reading now happens inside a future. should be safe since we don't have any other threads doing anything while we wait. - the future feeds into a buffer from which the main thread will take file segments and write them to disk - buffer has 4 segments and synchronizes the threads via wait conditions - the size of a segment is determined somewhat dynamically between 64kb and 4mb. the larger a file is the more it benefits from larger read requests under perfect conditions this yields approximately mount-level copy performance, unfortunately those are hard to hit so on average it's usually less (somewhere in the range of 10 to 20% depending on the actual file size and server type). compared to the old code this should more or less always be 100% faster for large files. multiple small files should see an equal improvement from what I've seen copying my kio-extras dir around. for some reason gains seem much greater against win10 servers, though that may be because the test systems I've set up are not having equivalent IO capabilities. in general, all of the above only applies to cases where the server's disk output will be able to saturate the request volume. TODO: this probably also needs extending to smbCopy (remote<->remote) and smbCopyPut (local->remote). smbcopy may need to not have threading though since we'd use the same smb_context in two threads TEST PLAN - fallocate -l 1G file - copy around - copy kio-extras around REPOSITORY R320 KIO Extras BRANCH thread-read REVISION DETAIL https://phabricator.kde.org/D27504 AFFECTED FILES smb/kio_smb_dir.cpp To: sitter, ngraham, cfeck Cc: kde-frameworks-devel, kfm-devel, pberestov, iasensio, fprice, LeGast00n, cblack, MrPepe, fbampaloukas, alexde, GB_2, Codezela, feverfew, meven, michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, emmanuelp, mikesomov
