> https://support.microsoft.com/en-us/help/2549369/performance-degrades-when-accessing-large-files-with-file-flag-random-access > > Although the optimization is good, it sounds like it is the typical Microsoft > designed-by-flock-of-idiots software. There is absolutely no way that this > should *ever* happen unless the cache was designed by complete utter morons. > Of course, knowing the history of this the code that "works properly" was > probably patented IBM technology that had to be removed and re-written > (defectively) by Microsoft after they stole OS/2 to develop Windows NT ... > > And I know that this "bug" is present still in Windows 10 1607. Don't know > if they have fixed it in 1703, but I kind of doubt it. Instead they added > "page compression" (that you cannot disable) to create even more problems. While there is a lot of controversy with how Windows handles Disk Cache, I don't think the problem I'm experiencing is related to that. I don't believe Windows will ever set an Active File Mapping for Disk Cache, since these are often tied to running processes/applications. I think the problem may be related to reading byte data (BLOBs) from a Database, since the Active File Map only seems to occur after reading BLOBs from a table, which is why I considered sqlite or the sqlite.net library may be reading from the disk with the wrong parameters or not properly freeing the resources after they've been used for reading BLOBs. I created that simple program (the one that just reads BLOBs over and over) just to help narrow down the problem.
To reiterate, the Active File Maps only seem to appear and persist for files/tables that I have read byte data (BLOBs) from. Which is why I think the problem is related to sqlite and reading byte data (BLOBs). On Friday, May 26, 2017 1:04 PM, Keith Medcalf <kmedc...@dessus.com> wrote: On Friday, 26 May, 2017 08:27, Jamie <eqrecov...@yahoo.com> said: >> <https://msdn.microsoft.com/en-us/library/windows/hardware/dn567645.aspx> >> says that there is a different kind of file cache for a random-access >> file, and that it shows up as active mapped pages. >> https://support.microsoft.com/en-us/help/976618/you-experience-performance-issues-in-applications-and-services-when-the-system-file-> >> cache-consumes-most-of-the-physical-ram > These pages are describing an unrelated problem with a Windows Service(s), > as those active pages under the category for METAFILE, and not under > Mapped File. https://support.microsoft.com/en-us/help/2549369/performance-degrades-when-accessing-large-files-with-file-flag-random-access Although the optimization is good, it sounds like it is the typical Microsoft designed-by-flock-of-idiots software. There is absolutely no way that this should *ever* happen unless the cache was designed by complete utter morons. Of course, knowing the history of this the code that "works properly" was probably patented IBM technology that had to be removed and re-written (defectively) by Microsoft after they stole OS/2 to develop Windows NT ... And I know that this "bug" is present still in Windows 10 1607. Don't know if they have fixed it in 1703, but I kind of doubt it. Instead they added "page compression" (that you cannot disable) to create even more problems. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users