How Tencent Docs Cut Desktop Memory Usage by 60% with Tombstone and Page‑Freeze Techniques

Background

Tencent Docs desktop uses Electron, rendering each opened document in a separate Chromium process. Every document adds a rendering process that consumes hundreds of megabytes, leading to total memory usage of several gigabytes, which caused user complaints and internal pressure to improve the situation.

Optimization Plan

Typical memory‑saving techniques such as code slimming, resource reuse, lazy loading, data‑structure optimization, and leak fixing were considered, but they require long‑term effort. Two faster‑to‑implement ideas were evaluated:

Container merging : Share a single container among multiple documents of the same type, reducing the number of rendering processes. A prototype showed noticeable re‑render delays, high development cost, and unclear benefits, so it was not pursued further.

Single‑process mode : Attempt to run Electron in Chromium’s single‑process mode via the --single-process flag. The approach proved unstable and is not supported by Electron, so it was abandoned.

Implementation

Phase 1 – Tombstone Mechanism

Inspired by iOS’s tombstone system, documents are classified as foreground or background. When a document stays in the background for more than 30 minutes and the total memory of background tabs exceeds one‑quarter of system RAM, the oldest background rendering process is terminated until usage drops below the threshold. When the user returns to the tab, the document reloads automatically, similar to Chrome’s low‑memory mode.

Phase 2 – Memory Cleaning and Page Freezing

On Windows, the EmptyWorkingSet API marks unused pages as removable, allowing the OS to reclaim them when memory is tight. This dramatically reduces a process’s working‑set size without noticeable performance impact, though reclaimed pages may be re‑loaded later.

Chromium provides an internal SetPageFrozen method that pauses CPU work for invisible pages, stopping timers, DOM updates, and JavaScript execution. By exposing this method in a custom‑built Electron binary, the client can freeze background pages, freeing CPU and enabling further garbage collection.

The combined strategy works as follows: after a document is background for 3 seconds, SetPageFrozen is called; after an additional 5 seconds, EmptyWorkingSet runs. Every minute the system checks if a renderer’s memory exceeds 50 MB and repeats cleaning if needed. When a tab becomes foreground, it is unfrozen and cleaning stops.

Results

Benchmarking six identical documents opened simultaneously showed:

Before optimization: total memory ≈ 2.5 GB.

After optimization: total memory ≈ 900 MB, a reduction of about 60%.

In version 3.9.0 the tombstone strategy reclaimed roughly 6 000 tabs per day with no reported negative user feedback.

Future Plans

Further reductions will target the number of renderer processes by moving more logic to the main process, continued code slimming, lazy loading, data‑structure refinement, and leak detection. Collaboration with product teams will aim to lower memory usage of detail‑page renderers, and research into container‑based architectures will continue.