<i> 700MB for gjs </i> Well, i'm obviously in the minority (despite this kind of system programming being my day job for the past 30 years), but JIT'ed Garbage

<i> 700MB for gjs </i> Well, i'm obviously in the minority (despite this kind of system programming being my day job for the past 30 years), but JIT'ed Garbage collected languages should never be part of the core system toolkit for actual technical reasons. gjs (and the kde equivilant) should have been kept as end user system scripting languages, rather than having shipped parts of the DE written in them. Its a large reason why lxqt is significantly lighter than KDE. It all comes down to the fact that no one has really solved the triumvirate of low latency, reasonable performance, and high collection rates, with a GC that aggressively returns unused ram back to the OS. Its a hard problem when the end application isn't known. For something like a generic control panel the (excluding event/loggging) the upper memory footprint can be bounded by the programmer, and the GC will be more aggressive as it approaches that limit, and the final result is a reasonable compromise. That said the hardcoded limit is likely 2X+ what would have been required by a non GC'ed environment. But for a general anything goes environment, the GC's are tuned towards performance and largely unbounded GC regions. Which means in order to maintain reasonable performance they will just keep reserving address space from the OS, touching parts of it temporary and then avoiding compacting it because those operations are very expensive. Plus with mozjs/spidermonkey (another whole set of problems for gjs due to the lack of a stable API) if the GC+JIT are aggressive about memory minimization then there can be frequent noticeable application lags as the memory is freed then reacquired from the OS/etc. Then because your desktop isn't under memory pressure, its not going to page out the fragmented bits of address space by default. Until it is under pressure, then the whole system goes laggy because while the LRU like algorithms the kernel is using to take the memory back work well, the GC is completely unaware of which bits of the address space it thinks it owns are suddenly going to respond much more slowly than it expects, and since its shotgunned (or worse is actually heap compressing everything) stuff all over the address space your taking a lot more pagein requests than one might expect. So the problem gets compounded. The end result (like with java on the server) is that what benchmarks well in a trivial sandbox by itself on a machine, starts to have longer term negative consequences when its sharing a machine with another application (or dozen) also written under the assumption that address space is free and the OS will just take care of the problem. So, javascript DE bindings are a good idea, but should have been reserved for windows macro recorder, or vba types of use cases rather than having parts of the default installed runtime env rewritten to use it.