[Performance] Insomnia is laggy when working with large request body strings

[Zero3]

• Insomnia Version: 5.14.8
• Operating System: Reproducible on Windows 7 and Windows 10

When working with large strings in request bodies, the request body editor in Insomnia becomes very laggy. These are some of the operations that all take multiple seconds to execute:

• Pasting a string
• Deleting any character in the string
• Selecting all request body with CTRL + A

The lag is clearly visible with a single ~100 KB strings. Using a single ~1 MB string, it is pretty unbearable, with every operation mentioned above taking multiple seconds to execute.

[gschier]

I was able to reproduce the "Select All" issue with a larger 4.5MB string but couldn't see any lag when deleting characters. Can you provide a sample string for testing purposes?

[mattjbrent]

I'm working with requests that return base64 strings currently and i'm experiencing this issue. It can take several seconds to display the text and editing it can be intermitently choppy.

Insomnia 5.14.9.1895
OSX High Sierra
MacBook Pro 2016

Im working with an API where I can receive incrementally large base64 strings so when I have time i'll make some requests and try log some times/actions on these strings

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Zero3]

Hey stalebot!

It's quite annoying that you keep closing my issues. I invested time in reporting them, and if they just get closed automatically when your owner don't fix them fast enough, I might be disencouraged from submitting new issues in the future. Maybe your owner doesn't want to encourage people to submit issues in the first place, of course... But that would be sad, wouldn't it? You would think that it would be appreciated. Either way, your disencouragement is working, because I'm quite annoyed with you by now :(.

(cc @gschier)

[gschier]

Sorry @Zero3! @stalebot works well for things like feature request but, I agree, can be annoying for bugs and issues like this that should be resolved.

[Zero3]

Thanks for reopening.

Regarding the issue at hand: Like Matt, I also noticed this issue when calling an endpoint that returned Base64 data. In my case, it was in a string field of a JSON object.

[hapablap21]

I'm having the same issue with request bodies that are large, regardless of encoding. Just ctrl-A on a big JSON blob inside the request window and insomnia freezes completely. In my usage, this is new since v6.0.2.

[rubin55]

I'm having this issue also: large request body slows things to a crawl. I suspect this has to do with the syntax highlighting? Is it possible to turn syntax highlighting off? In this case I'm working on an XML body, but I see exactly the same behaviour with larger JSON bodies. Wrapping long lines on/off seems to have no effect on the issue.

[gschier]

As a workaround for now, if you do not need to edit the JSON, it might be possible to attach the JSON as a file instead?

@rubin55 to test if it's the syntax highlighting, can you change the body type to "Other" and see if the problem continues? Also, as another experiment, can you turn on "Nunjucks power user mode" in the main app settings?

[rubin55]

Hi @gschier; when I change the body type from XML to Other, syntax coloring remains in effect. Thus I'm not sure that in that case I'm actually turning off something that could slow things down in this case. My test file is a 10000 line soap request body for a POST.

[gschier]

Ah yes, you'll need to also remove the Content-Type header too I think

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[eamigo86]

Please do not close this issue that still occurs:

Steps to reproduce:

• Bodies with big data structures (JSON or XML) or base64 strings

Tested too storing the base64 string in an Insomnia's environment variable

• Insomnia Version: 2020.3.3
• Operating System: MacOS Catalina 10.15.6
• Hardware Specs: i7-8750H + 32GB RAM + SSD 1TB

[mattjbrent]

I've since moved onto using Postman as this issue was a deal breaker for me. Still an issue 2 years later and is now closed out.

[HeCorr]

I've recently migrated from Postman which is now pretty much garbage (specially version 8) and just came across this issue.

I'm loving Insomnia but the UI lag is pretty annoying..

Can this please be reopened and looked into..? Thanks!

[dimitropoulos]

I'd like to know a surefire way to reproduce this - something of a baseline I might use to see if there's any kind of systemic issue that can be solved. Can anyone here provide an example request that creates the lag?

I hope it goes without saying, but just to say it, we definitely want the user experience with insomnia to be top-notch. While we have to make tough decisions when we're prioritizing (and that could mean not addressing this issue, even), it does wonders to have clear reproducibility with which we can measure improvements.

[HeCorr]

@dimitropoulos this one lags pretty badly (freezes for about 2 seconds when pressing spacebar in the middle of a base64 string):
https://gist.github.com/HeCorr/93ca21ce2d26ae146574ac0246df651c
It consists of three 4k images encoded in base64.

My pc specs:

Intel Core i5 3330s @ 2.7GHz
Corsair 8GB DDR3 @ 1600MHz
EVGA 1050Ti 4GB

If you have a better machine than this, you might need to duplicate a few items in the request to push it beyond 3MB.

[HeCorr]

As a side note... changing the body type to "Other" doesn't seem to disable syntax highlighting. it just keeps using the latest one (possibly a bug. I can open a different issue for that) so I can't really test if the lag is caused by syntax or just by a lot of text in the text box.

Edit: Clicking "No Body" and changing back to "Other" seems to correctly disable syntax highlighting but the issue remains so we can pretty much eliminate the highlight being an issue.

[HeCorr]

After some quick profiling:

A very small request (a few bytes), after pressing the enter key (new line)

A large request (about 3MB, the one from the gist link), after deleting a few characters from a base64 string

[dimitropoulos]

@Zero3 I'd like to personally apologize about that. If it's any consolation to you - we agree that there's been a lot of undue friction by the stalebot and decided yesterday that we're just going to remove it altogether. There's a PR that I expect to merge today to do so #3457. I don't know why it assigned you.. I've unassigned you.

Please let me know any issue that you worked on that the bot closed and I'll work with you on them to see where they're at and what we can do about it. I looked around and I just found the one #668 and I reopened it and left a comment (indeed, I think it's a good issue for you to have raised). please let me know if there are others I missed.

[wdawson]

Sorry folks! This was incorrectly tagged as a feature request along with other bugs. I'm going back through and cleaning up, sorry for the inconvenience.

[Zero3]

@dimitropoulos Thanks a lot :). Good to hear that you are working on improving things! Thanks for re-opening that other issue as well, which indeed was the one I had in mind. I appreciate it.

(I was re-assigned to this issue by just after you removed me though, by another bot, so it seems like your bot troubles are not quite over yet...)

[HeCorr]

From my testing, code mirror seems to lag just as much as Insomnia..

But Postman seems to handle huge texts very well.. even selecting and erasing everything takes less than a second:

2021-07-16.15-28-11.mp4

[Tjax33]

2022 and this is still a problem. It is very very easy to reproduce.

1. A large text of base 64 string inside of json body.

The performance is very slow and laggy

[wdawson]

We're looking at switching off of code mirror for this reason among others. Nothing to report yet on timelines but there's appetite on the team for sure.

[zocom-johan-kivi]

Im on a 665 row yaml for our API and am about 1/5 in. It is very sluggish ang laggy on my m1 pro. This bug makes me switch to Swagger hub or even postman.

[filfreire]

Linked with #3915 and #4890

[HeCorr]

Hello! I've just updated to version 2022.4.2 and the issue seems to be gone.

It's very responsive when scrolling through, selecting and editing a 144kb JSON request.

I do have a better computer now (Ryzen 7 3700x, 16GB DDR4 3600MHz), but I'm unsure if it's related.

(if I remember) I can try it on my dad's computer (which has my old parts) and see how's the performance on that.

[fawad-systems]

Hello! I am currently using Insomnia after the garbage corporate changes of Postman to login for importing and workspace. The UI is still very laggy with large amounts of Base64 strings.
I have a reasonable machine MBP 2020 (Quad-Core Intel Core i5, 16GB Ram).

While the payload request is open, the rest of the experience becomes a slog. I just don't want to switch to Postman for the whole signup thing but if this persists, I will have to as the second issue for me is that I can import Postman JSON but not the other way around.

Not to mention that executing said request gives me "out of memory error".

[cwangsmv]

When input more than 800,000 rows of data in request body and select all request body with CTRL + A, the Insomnia app will hang.
This is the issue from CodeMirror and can be reproduced in playground. Can use the big json data and copy-paste 10 times and select all the contents.

[garug]

Given codemirror seems related to this issue, is on radar to use codemirror 6 instead of actual version 5 used on project?

[cwangsmv]

Given codemirror seems related to this issue, is on radar to use codemirror 6 instead of actual version 5 used on project?

Replace CodeMirror5 is on track but there's no timeline yet. There's huge features depend on CodeMirror5 and even codemirror6 upgrade including some breaking changes.