We have hit into serious performance issues while accessing network files with our mini filter driver and we have narrowed it down to 3 filter manager calls that are causing significant performance degradation viz. FltGetFileNameInformation (normalized path), FltQuerySecurityObject, (owner/group and dacl/sacl information), FltQueryInformationFile (basic and standard information)
In order to narrow down the scope for the performance experiments, we tweaked our filter driver to just trap in PostOpCreate and make those 3 calls. We also wrote a simple test application (win32 console application) that just opens and closes the specified file specified number of times and measure the performance in controlled environment.
When we run our test application with our filter driver loaded,
For network files:
FltGetFileNameInformation causes 6x slowness.
FltQuerySecurityObject causes 3x slowness.
FltQueryInformationFile causes 2x slowness.
The cumulative slowness is around 10X.
For local files:
The cumulative slowness is around 2X.
Significant overhead is coming from FltGetFileNameInformation. We are calling it with NameOptions =
FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_ALWAYS_ALLOW_CACHE_LOOKUP
We found similar threads on the forum in the context of calling it from PreOpCreate. However, we are calling it from PostOpCreate. Further, some threads mention that this was an issue in earlier versions of Windows (e.g. XP). However, we are finding performance degradation in 64-bit Windows 2008 R2 as well
All the three calls are mandatory for functioning of our filter driver. Are there any optimizations that we can look for?
On other note, in our original filter (i.e. not the one tweaked for performance measurements) we cache the name information that we receive from FltGetFileNameInformation call in our stream context (allocated using FltAllocateContext with FLT_STREAM_CONTEXT). This ensures that for subsequent opens, we don't call the API again if the stream context is around. For local files, we see that Windows keeps the stream context around. However, for network files, we find that stream context is released as soon as the file is closed. Hence, with our test application, we get better numbers if we do open, open, open, close, close, close sequence instead of open,close,open,close,open,close sequence.