Why is copying files to/from a CBFS Connect drive so slow?

There are a couple of reasons why it can take longer to copy files to and from a CBFS Connect virtual drive:

Context Switches

CBFS Connect consists of a kernel mode filesystem driver and a user mode API library (i.e., the CBFS component) that work together in tandem to allow your application to implement a virtual filesystem. When the OS sends requests to that filesystem, the kernel mode driver invokes your user mode code using events, which causes a context switch; and then when your code is finished handling the event, another context switch back to kernel mode again. Furthermore, if your user mode event handler uses system APIs, then chances are good that another round of context switch (from user to kernel mode and back again) will occur.

Each context switch adds a small amount of overhead, and that can add up quickly, resulting in decreased performance. This is especially true when copying file data, especially if the data is copied in very small chunks (e.g., 64KB, as Windows Explorer sometimes uses). CBFS Connect includes several file data caching options, including use of the system's built-in file cache manager; this can certainly help improve performance, but there will inevitably still be some amount of performance impact due to context switching.

Global Locks

There exist certain drive-wide resources that must be guarded during events like CreateFile, OpenFile, and CloseFile. This requires the use of a global lock, which (when active) will block all operations on the drive until the current one completes. Use of such global locks is an unavoidable necessity in order to protect sensitive resources from concurrent modification, so your application is able to handle events such as those mentioned about, the less time it is necessary for CBFS Connect to keep a global lock active.

Illustration

The diagram below illustrates the concepts described in the preceding paragraphs. Please refer to the above sections for a detailed explanation.