FHR memory overhead is 3mb at the moment. It should be <300K during normal operation. I may be possible to reduce that to <100K. Majority of the code does not need to be loaded during data collection. A larger footprint is ok while serializing or uploading data.

As mentioned in bug 831397, I reckon >1MB of the background consumption is due to the overhead of using multiple JSMs/compartments. We can look into preprocessor or similar hacks to consolidate all the lines of code into a single file/compartment if we are desperate. But, I'd rather see the compartment model changed in the long run. I do not want to be in the business of ensuring random JSMs can be concatenated with other random JSMs. This almost completely undermines a primary purpose of JSMs: modular and reusable code.

(In reply to Gregory Szorc [:gps] from comment #1) > As mentioned in bug 831397, I reckon >1MB of the background consumption is > due to the overhead of using multiple JSMs/compartments. We can look into > preprocessor or similar hacks to consolidate all the lines of code into a > single file/compartment if we are desperate. But, I'd rather see the > compartment model changed in the long run. I do not want to be in the > business of ensuring random JSMs can be concatenated with other random JSMs. > This almost completely undermines a primary purpose of JSMs: modular and > reusable code. I agree with above sentiment(that JSMs impose costs). However if there are alternative ways to reduce footprint, we should pursue them. For example, we could do frequent collections in C++. Telemetry leans heavily on C++ to minimize footprint.

(In reply to Taras Glek (:taras) from comment #2) > However if there are > alternative ways to reduce footprint, we should pursue them. > For example, we could do frequent collections in C++. Telemetry leans > heavily on C++ to minimize footprint. I would accord a large cost in engineering time and maintenance to doing so, which IMO would outweigh most conceivable wins. We have plenty of other important things to work on instead of rewriting working code in C++, and there are probably much better candidates for reducing memory use by rewriting in C++. That doesn't mean it's not a valid work item, but it does mean that it's unlikely to be prioritized over other work that will drive market share. In other words: I agree if you replace "should pursue them" with "should consider pursuing them"! Volunteers to do the work in parallel are welcome, of course. I just want to be prudent when considering the value of Greg's time.

Calling this a meta bug, because it's not directly actionable.

As I was working on bug 834936, I made some very interesting observations. One of them was that by moving bagheeraclient.js from a standalone compartment in HealthReport.jsm, 50-60k from the standalone compartment was reclaimed while HealthReport.jsm's compartment only increased by 5k. My takeaway was that while bagheeraclient.js is only used during upload and thus it could potentially be unloaded while not in us, that seems like a lot to chase 5k. There are much better ways to reclaim 5k.

(In reply to Taras Glek (:taras) from comment #0) > FHR memory overhead is 3mb at the moment. FHR's current memory overhead is significantly less now. We freed 350+k with SQLite cleanups. We freed another ~750k in bug 834936. > It should be <300K during normal > operation. I may be possible to reduce that to <100K. I believe these numbers are unrealistic. For comparison, Telemetry's C++ component is in the 150-160k range and it's JS compartments are another ~450k. Granted, Telemetry does have many more active probes. Not sure how much of that RSS is in-memory measurements. Anyway, FHR uses ~80k for an active SQLite connection. And, each JS compartment is at least 55k. That's already 135k assuming we load into a single compartment (which we don't). Anyway, our main compartments for FHR now look like: │ │ │ ├──────202,600 B (00.03%) -- compartment([System Principal], jar:file:///Applications/FirefoxNightly.app/Contents/MacOS/omni.ja!/components/DataReportingService.js) │ │ │ │ ├──147,456 B (00.02%) -- gc-heap │ │ │ │ │ ├───57,920 B (00.01%) ── unused-gc-things │ │ │ │ │ ├───32,512 B (00.01%) ── objects/function │ │ │ │ │ ├───21,760 B (00.00%) ── sundries │ │ │ │ │ ├───17,664 B (00.00%) ── scripts │ │ │ │ │ └───17,600 B (00.00%) ── shapes/tree/global-parented │ │ │ │ ├───24,648 B (00.00%) ── script-data │ │ │ │ ├───21,280 B (00.00%) ── other-sundries │ │ │ │ └────9,216 B (00.00%) ── shapes-extra/compartment-tables │ │ │ ├──────462,040 B (00.08%) -- compartment([System Principal], resource://gre/modules/HealthReport.jsm) │ │ │ │ ├──315,392 B (00.05%) -- gc-heap │ │ │ │ │ ├──124,008 B (00.02%) ── unused-gc-things │ │ │ │ │ ├───73,840 B (00.01%) -- objects │ │ │ │ │ │ ├──49,440 B (00.01%) ── function │ │ │ │ │ │ ├──14,592 B (00.00%) ── ordinary │ │ │ │ │ │ └───9,808 B (00.00%) ── dense-array │ │ │ │ │ ├───52,072 B (00.01%) ── scripts │ │ │ │ │ ├───41,560 B (00.01%) -- shapes │ │ │ │ │ │ ├──32,880 B (00.01%) ── tree/global-parented │ │ │ │ │ │ └───8,680 B (00.00%) ── base │ │ │ │ │ └───23,912 B (00.00%) ── sundries │ │ │ │ ├───87,816 B (00.01%) ── script-data │ │ │ │ ├───23,568 B (00.00%) ── other-sundries │ │ │ │ ├───14,336 B (00.00%) ── shapes-extra/compartment-tables │ │ │ │ ├───12,736 B (00.00%) ── objects-extra/slots │ │ │ │ └────8,192 B (00.00%) ── cross-compartment-wrapper-table