Clemens, when I change to ullAvailVirtual the figure stays pretty much the same throughout the programme as you suggested. I still don’t understand the ullAvailPhys numbers though. Why would window’s increase it’s cache size during step ascending then reduce it during step descending in such a consistent manner?
If I code it to step through desc before asc this is the output Descending 13275 13276 13314 13314 13315 13315 Ascending 13315 11425 9525 7625 5722 3830 and again those results are repeatable. I don’t understand it but I’m convinced it’s not reacting to any other app. ________________________________ From: sqlite-users <sqlite-users-boun...@mailinglists.sqlite.org> on behalf of Clemens Ladisch <clem...@ladisch.de> Sent: Thursday, May 31, 2018 11:50:19 AM To: sqlite-users@mailinglists.sqlite.org Subject: Re: [sqlite] This is driving me nuts x wrote: > I’ve written the console app below to illustrate. It prints out the amount of > RAM available every 20 million steps. > GlobalMemoryStatusEx(&status); > return status.ullAvailPhys / (1024 * 1024); This is "physical memory currently available", which is affected by other things, such as the Windows file cache. Try ullAvailVirtual to see the how much your own process could allocate; this is affected by both your code and by the SQLite library. (This value is unlikely to change by much because SQLite's default cache size is 2 MB.) > It seems to lose RAM while step ascending and then give it back when step > descending. RAM that Windows chooses to use for the file cache is not lost. Regards, Clemens _______________________________________________ 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
