-
Notifications
You must be signed in to change notification settings - Fork 30.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pasting long json in REPL is slow #40626
Comments
Out of curiosity, what if you try doing $ TERM=dumb node and then pasting the string? It's not an actual solution, but it should disable the automatic preview which might be causing the slowdown. |
Yes, then the speed is comparable to other REPLs. PS: As to why one would ever paste so many characters: In my case I was pasting some json which I got from my browser (due to a complex authentication flow) but wanted to traverse and analyze in nodejs. My workaround was to go the extra step of saving the json to another file and then loading that in nodejs. |
The input is analyzed as @mscdex already outlined. Doing that for a big input could indeed be costly. Having a flamegraph for the specific situation (having a simple perf output would also be fine) would allow us to identify the specific part that is slow. If everything fails, we could limit the input evaluation only to be run for input up to a specific size. |
I am not sure how to generate such a profiling dump but I guess it should be easy to reproduce. Another possible solution would be to have a little debounce on the preview. Pasting data to the terminal results in a near-zero gap between each char as opposed to holding a key down for which the OS often uses a repetition delay. |
@septatrix Without checking closer: it would probably be useful to use a debounce time to trigger the preview. |
isolate-0x55ab4670d5f0-367032-v8.log (with 10k chars) |
The following two entries are the main entries.
It would be possible to use a special |
@septatrix you might want to check #41005. This could already improve the situation a bit. |
i experimented with this in the prototype repl a bit. you can get a somewhat reasonable handling of this by only highlighting/evaluating/etc between each stdin |
Is there some easy way to try it out (besides compiling from source)? |
@BridgeAR I vote for the debounce time too. But wondering what would happen if a user just pastes |
Version
v14.18.1
Platform
Linux thinkpad-e570 5.14.13-200.fc34.x86_64 #1 SMP Mon Oct 18 12:39:31 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
¹ The effect can be observed starting at ~2000 chars on my pc with an Intel i7-7500U (4) @ 3.500GHz).
I generated the data using
cat /dev/zero | head -c 2000 | tr "\0" 0 | wl-copy
How often does it reproduce? Is there a required condition?
It is consistent and becomes more noticeable with a larger clipboard content
What is the expected behavior?
The pasting should happen instantaneous
python-repl.mp4
What do you see instead?
One can see how the content trickles in bit by bit
nodejs-repl.mp4
Additional information
I am using Gnome Terminal but can observe the same behaviour in other terminals like Alacritty. The cpu utilization when pasting goes up to 100%. Other REPLs like python do not show the same behaviour.
The text was updated successfully, but these errors were encountered: