Memory Issue when continually using Nushell

[theAkito]

Describe the bug

This is a vague observation. Not sure, how to investigate.

When playing around in Nushell, the terminal gets slower, slower & slower...

The memory used by /usr/bin/nu is 1.0 GiB & virtual 1.5 GiB. I can confirm the 1.5 GiB with various external Linux tools.

The CPU usage seems overly high for a terminal, as well.

How to reproduce

1. Open a Nushell instance.
2. Play around in it, like e.g. use let-env, def, $env, $nu and further Nu features.
3. Keep playing around, until you notice, how everything becomes slower & slower.

Expected behavior

No CPU, memory & performance issues should arise just from doing something in the shell.

Screenshots

No response

Configuration

key	value
version	0.71.0
branch
commit_hash	6cc4ef6
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.65.0 (897e37553 2022-11-02)
rust_channel	stable-x86_64-unknown-linux-gnu
cargo_version	cargo 1.65.0 (4bc8f24d3 2022-10-20)
pkg_version	0.71.0
build_time	2022-11-08 18:00:26 +00:00
build_rust_channel	release
features	database, dataframe, default, trash, which, zip
installed_plugins	partial

Additional context

Platform
Debian GNU/Linux 11 (bullseye) in WSL2 on Windows 10

Terminal software
Visual Studio Code integrated Terminal

Nushell is running "natively" as a login shell.

Opening a new Nu terminal does not have these issues. The issues just arise after playing around with a single instance for quite a while.

[fdncred]

Two things that I can think of that would be helpful in figuring this out are this. When you see this problem again, please report back with the output of these commands.

$nu.scope.engine_state

and

echo one | debug -r

[theAkito]

For the sake of testing, I let the affected terminal run in the background since I posted this issue.

Faulty Terminal

$nu.scope.engine_state

┏━━━━━━━━━━━━━━┳━━━━━━━━━┓
┃ source_bytes ┃ 1971920 ┃
┃ num_vars     ┃ 23147   ┃
┃ num_commands ┃ 2968    ┃
┃ num_aliases  ┃ 2500    ┃
┃ num_blocks   ┃ 9302    ┃
┃ num_modules  ┃ 148     ┃
┃ num_env_vars ┃ 39      ┃
┗━━━━━━━━━━━━━━┻━━━━━━━━━┛

echo one | debug -r

String {
    val: "one",
    span: Span {
        start: 1971925,
        end: 1971928,
    },
}

Fresh Terminal

$nu.scope.engine_state

┏━━━━━━━━━━━━━━┳━━━━━━━┓
┃ source_bytes ┃ 87640 ┃
┃ num_vars     ┃ 955   ┃
┃ num_commands ┃ 573   ┃
┃ num_aliases  ┃ 103   ┃
┃ num_blocks   ┃ 468   ┃
┃ num_modules  ┃ 7     ┃
┃ num_env_vars ┃ 35    ┃
┗━━━━━━━━━━━━━━┻━━━━━━━┛

echo one | debug -r

String {
    val: "one",
    span: Span {
        start: 87645,
        end: 87648,
    },
}

The "fresh" terminal was kept open since I created this issue, though I haven't done anything with it, yet.

Weirdly enough, the RAM consumption in the faulty terminal has not sunken a single bit, yet the performance in terms of speed is back again. I do not notice any speed issues anymore, when testing the same commands I tested for this issue, in the first place. Feels like a queue of some sorts cleared up in the meantime. Still, even then, the RAM consumption is precisely the same as before. 1.0 GiB | 1.5 GiB

[fdncred]

I think this is a known issue that when spans get large, nushell slows down. It sounds like that's what is going on.

[theAkito]

I think this is a known issue that when spans get large, nushell slows down. It sounds like that's what is going on.

Is there already an issue associated with this problem?
Can this be fixed easily?

[fdncred]

There may be an issue, I haven't looked.

Easily? Probably not. I think it may require some type of garbage collection.

[theAkito]

Easily? Probably not. I think it may require some type of garbage collection.

Is the source of the issue known and solvable or is it undetermined, yet?

[fdncred]

I'm no expert but I believe this is known. I think it's because none of these ids get reused. If you create a thing, then up arrow and edit it to tweak something, then do that again, you've created 3 ids instead of just having 1 that was edited twice. That's my layman's description.