Extremely slow project opening

[nlassaux]

I have checked the following:

• [X] I use the newest version of bruno.
• [X] I've searched existing issues and found nothing related to my issue.

Describe the bug

When loading the collection, Bruno's stuck for about 30 to 40sec, stops responding, consumes a ton of resources (120% CPU), and then becomes reactive again. This adds a ton of friction when running some quick debugging.

Intuitively, if bruno loads all 31 files, I can imagine that loading time being close to 5s maybe (not accounting for the UI itself, but from my tests the UI seems -visually- to be loading pretty quickly).

.bru file to reproduce the bug

Unfortunately I have some API keys in there, is there any way I can help without sharing the whole file? I have 31 requests, with about 5 of them that either use or return a 1MB payload. Maybe 2MB at most for one of them.

Screenshots/Live demo link

[gemiusz]

Bruno Version:1.18.1

I make little tests and have same issue :)

I have prepared Collection for this ticket.

Collection: GeMiusz_Bruno_BUGS.zip

On my machine (Windows 11, 12CPU, 16GB RAM, SSD) it take 1min 15s to open this collection.

Below stats from TaskManager:

It take 33s of CPU time, average CPU use 5% and maximum utilisation of RAM was 2 673 812 KB.

I hope that data from my tests and prepared collection will be useful for testing and optimization.

[Its-treason]

The culprit here is definitely the .bru file parser:

But not really sure, if that can be improved, because parsing is handled by a third-party library ohm-js, see: https://github.com/usebruno/bruno/blob/main/packages/bruno-lang/v2/src/bruToJson.js

[gemiusz]

Maybe it's possible to do "parsing" in threads or in background without hanging application, WDYT?

[nlassaux]

I don't know if it's relevant, but it looks like ohm-js is all about usability and not efficiency from what I read on their repo. Here is a benchmark I found to compare with alternatives: https://chevrotain.io/performance/

It looks like a pretty large gap vs others actually:

[nlassaux]

@Its-treason If you go down further in that call stack, do you see any of the functions that are defined in that file? https://github.com/usebruno/bruno/blob/main/packages/bruno-lang/v2/src/bruToJson.js.

Did you compute the flamegraph using Electron's built in performance analysis?

I wonder if list operations, merges, etc. can be optimized if they are being called a gazillion times recursively.

[Its-treason]

@nlassaux I redid the Perfomance recording. It seems to be mostly internal ohm-js functions being called. I attached the CPU-Profile you can open it in Chrome devtools (Perfomance -> Load profile..) and this is the bruno-lang JS-Bundle i used: https://pastecode.io/s/xyjc3qaw

bruno_gemiusz_performance.cpuprofile

[nlassaux]

Thank you! It does seem to be library-bottlenecked indeed. Testing a thing or two to see if I can improve that

[nlassaux]

Trying parsimmon as a parser replacement here: https://github.com/nlassaux/bruno/blob/feature/new-parsimmon-parsing/packages/bruno-lang/v2/src/bruToJsonNew.js

Opening your collection is almost instant @gemiusz. It's night and day from a usability point of view:

Before: 9 secs minimum

Now: 40ms maximum

gemiusz:

https://github.com/usebruno/bruno/assets/1917120/c27c54c0-aa15-406f-8ad0-842a9b031b70

Same for my collection. No more expensive loads anymore.

It doesn't pass all tests yet, but it opens our collections, enough for this test :)

[gemiusz]

@nlassaux I wondering if this will resolve issue [BUG] Poor responsiveness of application when using big collection e.g. 3000 .bru files too. I have prepared there collection that can be used for testing.

[nlassaux]

Good question! Just checked @gemiusz:

• Loading files is faster (2s vs 4s), but interactions are still pretty slow in the UI
• This change seems to provide crazy improvements for large payloads and small improvements for smaller payloads

[pottsga]

Any update on this? I'm experiencing this as well.

[nlassaux]

I don't think the main branch received any update regarding that problem. The parser is the issue, so porting the grammar to a new parser should do the trick. But it's also a critical area, we'll need a ton of tests and all to make sure nothing breaks in the process.

[Headbucket]

I have a similar problems with the current version (1.26.0). I have two requests in my collection with a super large json body (1,5 MB and 9 MB). Bruno takes about 30-45 seconds to start, when this collection is open.

Is there a possibility to implement something like "lazy loading"?

I have the same requests in the VS Code Extension "ThunderClient". ThunderClients loads the requests only when I select them and not before, so VS Code and the Extensions starts quick.