The event that is "slow" is when a third party program (Not our own, but one that wants to use our virtual drive) browses to a folder and opens it.

When testing against a hard drive, using the same files as the virtual drive (we just copy the virtual drive to a disk folder), browsing to a folder takes less than a second

When testing against the virtual drive, loading the folder takes 6-7 seconds

When testing using the CBFS example app (Mapper I think?) which points to a disk copy of the Virtual Drive contents, it takes 8+ seconds. Noticeably slower than the virtual drive.

Looking at what the third part program is doing, it creates several temporary files, and reads/writes to these (and other files the virtual drive offers)
Specifically in the case of the temp files, it reads from them in 28 byte chunks, and reads from them a lot.

Over the 6 seconds it takes to open the folder, the app calls the CbfsRead 97,000 times and CbfsWrite 32,000 times.

We profiled the event, and the various callbacks and procedures don't seem to take 6 seconds. The profiler does come back with a "Waiting for synchronization" event that takes up almost all the missing time. Not sure what that means.

Transition to managed code takes less than 700ms

Using another program that does something very similar is almost instant, but rather than 97,000 read calls it was doing less than 6000.
Other than this, the virtual drive works well, and seems to look the same as the physical versions to the test apps.

The samples are located in folders with different names, and the samples are named differently in documentation. So now I am confused even more. Since I didn't see those samples, I can't guess from your description, which ones you are referring to.

So... what are you comparing to what? 7+ seconds can be both slow and fast, depending on what you are comparing it to.

Thank you, now it's more clear. You need to understand that calling back the user-mode code adds significant time to the total time needed to process the request. In case of Mapper sample, which redirects requests to another folder/disk, this time is even more increased because the request from your application goes to the kernel, then back to the callback handler in user mode, then again to the kernel (to read the data from the real disk), then this data is passed back to the user mode and back to the kernel. And only then it goes to your application. I.e. there are several extra kernel mode - user mode switches in this case. And if your application reads data in small chunks, then handling of such requests will be very slow (especially with unoptimized Mapper sample).

However, 7 seconds for browsing a directory with 100 files is not ok. Did you try reading the virtual disk's directory from Explorer? Does it give the same time?

Also please check VDisk or VMounter samples and see how different they are in time. This will give us some additional information.

The VDisk/VMounter samples aren't really going to give us anything, they are all very fast

Browsing the one of our Cbfs folders in Explorer is also fast as is using the Mapper example.

The issue is the temp files this third party app is writing when it browses to a folder.

As I mentioned in my first email above, it does 97,000 CbfsRead calls and about 32,000 CbsfWrite calls to a bunch of temp files it creates on the current folder every time a user browses to it.

We don't know why it does these calls, but the calls tend to be about 28 bytes in size for each one. Our guess is it reads 2 master index files, takes that information and writes a lot of temporary information, one "record" at a time to temp files it creates in the folder

That's fine when writing directly to a HDD folder, it's fast.
But when doing it via the Mapper example or our own Cbfs service, it's terribly slow.

We use cookies to help provide you with the best possible online experience. By using this site, you agree that we may store and access cookies on your device. You can find out more about and set your own preferences here.