Bugzilla

The very slow compilation is due to the presence of the debugger.  Contrast these two programs:
```
eval(`new WebAssembly.Module(read("/home/lhansen/moz/rustc_binary.wasm","binary"))`);
```
which compiles the test case in about 2s, and this one:
```
var g = newGlobal({newCompartment: true});
var dbg = new Debugger(g);
dbg.onNewScript = (function(script) {
    s = script;
})
g.eval(`new WebAssembly.Module(read("/home/lhansen/moz/rustc_binary.wasm","binary"))`);
```
which takes more than 20s.  (The "eval" in the first one is obviously unnecessary but is there for parity.)

The memory use is also due to the debugger.  In the first case, memory use ends up at 215MB, while in the second case, the shell grows to about 1.9GB.

Clearly there are problems here that need to be addressed, though those are not related to the console holding on to the debug code forever.

The very slow compilation is due to the presence of the debugger.  Contrast these two programs:
```
eval(`new WebAssembly.Module(read("/home/lhansen/moz/rustc_binary.wasm","binary"))`);
```
which compiles the test case in about 2s, and this one:
```
var g = newGlobal({newCompartment: true});
var dbg = new Debugger(g);
dbg.onNewScript = (function(script) {
    s = script;
})
g.eval(`new WebAssembly.Module(read("/home/lhansen/moz/rustc_binary.wasm","binary"))`);
```
which takes more than 20s.  (The "eval" in the first one is obviously unnecessary but is there for parity.)

The memory use is also due to the debugger.  In the first case, memory use ends up at 215MB, while in the second case, the shell grows to about 1.9GB.

Clearly there are problems here that need to be addressed (time, memory use), though those are not related to the console holding on to the debug code forever, they just make that problem (much) worse.

The very slow compilation is due to the presence of the debugger.  Contrast these two programs:
```
eval(`new WebAssembly.Module(read("/home/lhansen/moz/rustc_binary.wasm","binary"))`);
```
which compiles the test case in about 2s, and this one:
```
var g = newGlobal({newCompartment: true});
var dbg = new Debugger(g);
g.eval(`new WebAssembly.Module(read("/home/lhansen/moz/rustc_binary.wasm","binary"))`);
```
which takes more than 20s.  (The "eval" in the first one is obviously unnecessary but is there for parity.)

The memory use is also due to the debugger.  In the first case, memory use ends up at 215MB, while in the second case, the shell grows to about 1.9GB.

Clearly there are problems here that need to be addressed (time, memory use), though those are not related to the console holding on to the debug code forever, they just make that problem (much) worse.

The very slow compilation is due to the presence of the debugger.  Contrast these two programs:
```
var g = newGlobal({newCompartment: true});
g.eval(`new WebAssembly.Module(read("/home/lhansen/moz/rustc_binary.wasm","binary"))`);
```
which compiles the test case in about 2s, and this one:
```
var g = newGlobal({newCompartment: true});
var dbg = new Debugger(g);
g.eval(`new WebAssembly.Module(read("/home/lhansen/moz/rustc_binary.wasm","binary"))`);
```
which takes more than 20s.

The memory use is also due to the debugger.  In the first case, memory use ends up at 215MB, while in the second case, the shell grows to about 1.9GB.

Clearly there are problems here that need to be addressed (time, memory use), though those are not related to the console holding on to the debug code forever, they just make that problem (much) worse.

(Moved to bug 1714086.)