1. 17 May, 2021 1 commit
  2. 24 Jul, 2020 1 commit
    • Tobias C. Berner's avatar
      Add missing <array> include · 16ebb781
      Tobias C. Berner authored
      smb/transfer.h:70:62: error: implicit instantiation of undefined template 'std::__1::array<std::__1::unique_ptr<TransferSegment, std::__1::default_delete<TransferSegment> >, 4>'
          std::array<std::unique_ptr<TransferSegment>, m_capacity> m_buffer;
                                                                   ^
      /usr/include/c++/v1/__tuple:219:64: note: template is declared here
      template <class _Tp, size_t _Size> struct _LIBCPP_TEMPLATE_VIS array;
                                                                     ^
      1 error generated.
      16ebb781
  3. 04 Jun, 2020 1 commit
  4. 07 Apr, 2020 1 commit
    • Harald Sitter's avatar
      smb: make all qmin and qmax explicitly typed off_t · f4da469b
      Harald Sitter authored
      also explicitly set the min/max constexprs to off_t explicitly.
      this should now make all related calls act exclusively on concretely typed
      off_ts and as a result build on all platforms with all compilers 🤞
      
      BUG: 419702
      f4da469b
  5. 03 Apr, 2020 1 commit
    • Harald Sitter's avatar
      smb: fast copy · 46b5fb42
      Harald Sitter authored
      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).
      
      for many tiny files performance is about where it was before. the larger
      the files get the greater the gains from this diff though.
      
      specifically here's some samples I've taken:
      
      - for downloads from windows10
        - 1G & 4G file
          - compared to 20.04 is ~77% faster
          - within 10% of windows
        - 8G file
          - compared to 20.04 is ~79% faster
          - within 5% of windows
      - uploads to windows10
        - all sizes
          - compared to 20.04 is ~50% faster
          - now comparable performance to windows
      - for remote-to-remote file copies from windows10 to smbd 4.11.6
        - 1000 x 5K files
          - no change, dreadfully slow, likely problem in KIO internals
        - 1G file
          - compared to 20.04 is ~45% faster
          - within 8% of windows
        - 4G file
          - compared to 20.04 is ~95% faster
          - and somehow 18% faster than windows (could be a fluke)
      
      I've done transfers for 128M, 256M, 512M, 1G, 4G and partially 8G.
      Differences not mentioned are either unchanged, negligible or in line with
      documented trends.
      
      BUG: 291835
      FIXED-IN: 20.08
      
      Test Plan:
      - fallocate -l 1G file
      - copy around
      - copy kio-extras around
      
      Reviewers: ngraham, cfeck, #frameworks, #dolphin
      
      Subscribers: mmustac, meven, hallas, anthonyfieroni, asturmlechner, kde-frameworks-devel, kfm-devel
      
      Tags: #dolphin, #frameworks
      
      Differential Revision: https://phabricator.kde.org/D27504
      46b5fb42