WSL Performance Issues about bruno

[Its-treason]

I suspect that read/write operations on WSL are sometimes kinda slow. This should normally not freeze the UI, but Bruno mostly uses synchronous operations (fs.writeSync) instead of asynchronous (Everything from fs/promises).

I add this to my to-do list and test this the next few days.

[krummbar]

It's just a blind guess though. Reporting back would be beneficial in any case. Imho if the Problem is related to git, Performance should bei improved. Specially since it is a payed feature

[BoscoDomingo]

@krummbar Even with Git disabled, program still hangs:

[Its-treason]

Hey @BoscoDomingo, thank you for taking the time and doing some performance recordings. You can either message me on Discord: https://discord.com/users/139058134596583424 Or email me [email protected]. I don't have much time today, so will be looking at the recording tomorrow.

[krummbar]

Since you're mentioning golden edition. Did you try disabling the git Integration Feature?
I've observed some performance issues with it being active and having a couple of collections in place. If this improves things this may be a good indicator of the underlying issue.

[BoscoDomingo]

Since you're mentioning golden edition. Did you try disabling the git Integration Feature? I've observed some performance issues with it being active and having a couple of collections in place. If this improves things this may be a good indicator of the underlying issue.

@krummbar That seems to work. I've also disabled API Spec since I didn't use it, but I'll give this a try. If I don't report back, assume the issues are gone and Git integration is the culprit

[Its-treason]

I investigated this a bit. I moved a collection with around 30 requests into a WSL folder but didn't notice any freezes. To be sure, I also moved a collection with approximately 2,000 requests into WSL. I only experienced the usual ~5 second lag when interacting with the large collection, but this didn't cause any "window not responding" issues.

Could you share more information about your system?

Also, if you're confident with debugging Electron, you can attach a debugger as described here: Electron Debugging Guide and do a performance recording.

[BoscoDomingo]

@Its-treason Hi, sure I can. Do you need hardware specs, OS version...? And I could try to debug Electron, although I just came back from holidays and this is for my work machine, so it may take a while before I can take a dig at it 👍🏼

[BoscoDomingo]

@Its-treason Still a problem in 1.25.0. I even deactivated my Gold license to see if that was part of the issue but to no avail. I'll try a performance recording to see if that helps. I've never worked with Electron but I assume it's just cloning the repo and running it, correct?

Edit: I've a few performance recordings in which the program hung for a few seconds, even getting the (Not responding) message in the title bar. Let me know how to send them to you privately 👍🏼

[BoscoDomingo]

@Its-treason Shooting an email 👍🏼

[Its-treason]

Hey @BoscoDomingo, thank you for the recording! I've had a look into your recordings, and it's quite interesting, because it has nothing to do with IO but, it's just the .bru file parser that is really slow.

This was already noted here: #2416 and it just seems that parsing files with 1–2 MB in size takes an about ~10 seconds of parsing. Because parsing is done in sync inside the main thread, this also blocks the render thread, resulting in a window not responding message.

What interests me now: How big are your .bru files? There was one outlier in the CPU Profile that took 2 seconds for parsing, so that file should have been around 200 KB - 400 KB in size. If all your files are small (under 10 KB) there is something other that causes the parser to perform even worse. Parsing around 50 files should not take 13 seconds.

[BoscoDomingo]

@Its-treason Interesting find for sure. I've checked and the largest .bru files in my system are 12KB, so there's definitely something up with the parser: