The Windows Task Manager shows various types of "memory usage" and that is different depending on how the wind blows at the moment. In fact, even the how the "name descriptions" given in the Windows Task Manager correspond to actual memory management values is subject to how the wind blows at the moment one is looking. That is, Windows is a magical mystical beast and the numbers reported by any of its memory management subsystems only have vague correspondence (if any) to what a knowledgeable professional in the area of virtual memory management might call them.
That said, there are the common "Memory Size" numbers available through Task Manager (Windows 10 Pro for Workstations v.1903) and what they mean in "normal" terms: Working set (memory) - sum of "Working set (private)" and "Working set (shared)" (typically equivalent to VMSize) Peak working set (memory) - high water mark of "Working set (memory)" since process started Working set delta (memory) - Change in "Working set (memory)" since last time measured Memory (active private working set) - Theoretically the current process private V:R size (that is, the private memory resident size) Memory (private working set) - Memory that is allocated to the process (and cannot be shared) (may or may not be committed memory) Memory (shared working set) - Memory that is allocated to the process (that can be shared) (may or may not be committed memory) Commit size - The portion of the Virtual Memory allocated to the process which requires backing store, including discardable pages, but excluding uncommitted pages. By default, Task Manager shows the "Memory (active private working set)" (ie, Resident Private Bytes) in its display. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: sqlite-users <sqlite-users-boun...@mailinglists.sqlite.org> On Behalf >Of Jens Alfke >Sent: Monday, 9 September, 2019 16:18 >To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> >Subject: Re: [sqlite] SQLITE and the memory > > > >> On Sep 8, 2019, at 2:12 PM, Philippe RIO <51...@protonmail.ch> wrote: >> >> I use the windows task manager to see how the memory is used > >I don't use Windows, but I know that in any modern OS, memory usage is a >very vague thing and is tricky to measure. There are quite a few numbers >that mean different things, like >- actual RAM in use by the process >- virtual address space allocated >- address space with backing store assigned to it >- address space not being shared with other processes >- address space that's writeable >- address space used for 'malloc' heaps >- address space actually in use in heaps >etc. > >I find that when looking at memory usage of a program I'm working on, the >stats related to heap space are the most useful because they correspond >with memory my code is involved in allocating and managing. The farther up >that list you go, the more you see the effects of things like memory-mapped >I/O, shared library sizes, filesystem caches, and other things that are >usually out of your control. > >Specific to SQLite: it's usually pretty easy to manage the amount of memory >it uses because most of it is block caches, which you can customize the >size of yourself with pragmas. > >—Jens >_______________________________________________ >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
