Last Comment Bug 575667 - split about:memory reporting into more detailed sections
: split about:memory reporting into more detailed sections
Status: RESOLVED FIXED
:
Product: Toolkit
Classification: Components
Component: Storage (show other bugs)
: unspecified
: x86 Windows 7
-- normal (vote)
: mozilla2.0b3
Assigned To: Shawn Wilsher :sdwilsh
:
: Marco Bonardo [::mak]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-29 09:47 PDT by Mike Shaver (:shaver -- probably not reading bugmail closely)
Modified: 2010-07-22 10:12 PDT (History)
7 users (show)
sdwilsh: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1.0 (2.88 KB, patch)
2010-07-21 06:48 PDT, Shawn Wilsher :sdwilsh
vladimir: review+
vladimir: approval2.0+
Details | Diff | Splinter Review

Description User image Mike Shaver (:shaver -- probably not reading bugmail closely) 2010-06-29 09:47:53 PDT
Probably want one item per database for cache, one per database/connection for prepared statements, similarly for in-memory tables.
Comment 1 User image Shawn Wilsher :sdwilsh 2010-06-29 10:05:38 PDT
In order to do this, we'll need some new APIs (or an expansion of existing APIs) from SQLite.  What I think we'd need:
1) Given a sqlite3*, how much memory is used for the page cache
2) Given a sqlite3*, how much memory is used for currently compiled statements

This might go best on sqlite3_db_status.
Comment 2 User image Mike Shaver (:shaver -- probably not reading bugmail closely) 2010-06-29 10:15:01 PDT
Will that cover in-memory tables, like the ones that are currently used for places temp tables?
Comment 3 User image Shawn Wilsher :sdwilsh 2010-06-29 10:15:55 PDT
(In reply to comment #2)
> Will that cover in-memory tables, like the ones that are currently used for
> places temp tables?
I would think so, but that's something we can make sure gets covered too.
Comment 4 User image Shawn Wilsher :sdwilsh 2010-07-20 05:20:49 PDT
From drh:
You can get some extra global memory usage information
from sqlite3_status().  Specifically, if you look at the return from
sqlite3_status(SQLITE_STATUS_PAGECACHE_OVERFLOW,...) then (assuming that you
have *not* configured a separate chunk of memory designated specifically for
page cache, which presumably you have not) all page cache memory allocations
will be overflow allocations and so the result will show the current and the
peak amount of memory SQLite is using for page cache across all database
connections.  If you then subtract that amount from the total memory used,
you will get a reasonable estimate of the total memory used for compiled
statements.  Well, compiled statements + parsed schema storage + whatever
memory is being used but currently running queries.  That' isn't perfect,
but you could at least split the current about:memory line for sqlite into
two lines - one for sqlite.pagecache and another for sqlite.other.  I think
that would be a useful addition to about:memory and it doesn't require any
SQLite changes.


So, going to do that here, and when we get the new API, I'll open up a new bug.
Comment 5 User image Shawn Wilsher :sdwilsh 2010-07-21 06:48:14 PDT
Created attachment 458994 [details] [diff] [review]
v1.0

Threw this together while I was waiting for my plane yesterday.
Comment 6 User image Shawn Wilsher :sdwilsh 2010-07-22 10:12:45 PDT
http://hg.mozilla.org/mozilla-central/rev/c4720f6b9be4

Note You need to log in before you can comment on or make changes to this bug.