Question
Repeated <py-env> additions cause steady WebAssembly memory growth in PyScript
Rahul Indigo
0 reputation · 07 Dec 2023, 06:16 UTC
66.6K views1
Loading…
0 reputation · 07 Dec 2023, 06:16 UTC
When developing long‑running PyScript pages that dynamically insert and remove <py-env> blocks to load different packages, developers notice a gradual increase in the reported WebAssembly memory usage that does not drop after each removal.
The goal is to ascertain whether this growth is an intended side‑effect of Pyodide’s module caching or a sign that the interpreter state should be explicitly released. Current documentation does not specify a method to reset the interpreter or free the associated WASM memory, and the effect may differ between PyScript releases.
Is there a supported way to release or reset the Pyodide interpreter state without reloading the page? Does PyScript provide an API to reclaim WebAssembly memory allocated for loaded packages? Should this memory growth be treated as a leak requiring mitigation, or is it acceptable given that memory is reclaimed on page unload?
There is no built‑in PyScript API to reset or free the Pyodide interpreter without reloading the page. The only reliable way to reclaim the WebAssembly memory is to ensure no JavaScript reference to the pyodide instance remains, allowing the browser’s garbage collector to free the associated ArrayBuffer.
Each <py-env> element creates an independent Pyodide runtime. The runtime owns a WebAssembly Module and its memory buffer (an ArrayBuffer). When the element stays in the DOM, PyScript keeps a reference to the pyodide object, so the buffer is not released. Repeatedly adding new <py-env> tags therefore adds new buffers, and the old ones stay allocated.
pyscript<py-env> element does not automatically delete the interpreter reference unless PyScript explicitly clears it.<py-env> per page and load additional packages by updating its packages attribute or by using <py-script> that shares the same environment.delete window.myPyodide; or setting the variable to null).window.gc() if the Chrome flag is enabled) to verify that the memory drops.dispose() or destroy() method on the pyodide object; if it does, call it after removing the element.Does the version of PyScript you are using provide a public method to release the pyodide instance (e.g., pyodide.dispose())? Knowing this would change the recommendation from relying solely on garbage collection to calling that method directly.
Use comments to ask for clarification. Post a solution as an answer.
33,275 reputation · 07 Dec 2023, 17:21 UTC
When dynamically managing <py-env> blocks, the memory growth is typically a result of how Pyodide handles its WebAssembly linear memory. Each block initializes a separate interpreter instance with its own ArrayBuffer. Simply removing the element from the DOM does not necessarily trigger garbage collection of the buffer if the PyScript runtime maintains internal references to the interpreter object.
Currently, there is no stable API to force a memory release or reset of the Pyodide interpreter state without a full page reload. The growth is often an intended side-effect of module caching to ensure performance for subsequent imports within the same runtime session.
<py-env> block and manage dependencies via JavaScript-based loading rather than multiple DOM elements.null to allow the browser's GC to eventually reclaim the memory.iframe; removing the iframe is the most reliable way to purge the WASM memory.