Open nlassaux opened 3 months ago
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.
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
Maybe it's possible to do "parsing" in threads or in background without hanging application, WDYT?
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:
@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.
@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
Thank you! It does seem to be library-bottlenecked indeed. Testing a thing or two to see if I can improve that
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 :)
@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.
Good question! Just checked @gemiusz:
Any update on this? I'm experiencing this as well.
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.
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.
I have checked the following:
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