Performance issues with large collection variables

[stickpin]

Internal - [BRU-4312]

I have checked the following:

• I have searched existing issues and found nothing related to my issue.

This bug is:

• Making Bruno unusable for me.
• Slowing me down but I'm able to continue working.
• Annoying.
• This feature was working in a previous version but is broken in the current release.

Bruno version

4.0.0

💻 Operating System

macOS

Specific OS Version / Distro

26.6.1 (25G76)

🐞 Describe the bug

Hi team,

I am currently in the process of migrating my workflows from Postman to Bruno, but I am hitting a performance bottleneck with a large collection.

• Collection size: ~3,850 requests
• Collection variables: ~360 variables

Editing, scrolling, and navigating the Collection Variables tab in the GUI is extremely slow and glitchy. In the attached video, you can see the scrolling issues, and around the 30-second mark, I try to type—even typing very slowly, it takes almost 30 seconds for the characters to reflect in the UI.

To isolate the issue, I tried importing the same set of variables into a clean, empty collection, and the UI ran completely fine with no lag. The issue appears to be specific to the combination of having a large collection and a large number of collection variables simultaneously. Furthermore, using these same variables at the Global level works fast and smoothly.

In my previous setup (Postman), I used workspace variables to share context across requests during runner/CLI executions. Since Bruno CLI currently does not support passing Global variables via command line arguments, I am stuck between GUI performance issues and CLI limitations.

Is there a known workaround or planned fix for the Collection Variables tab performance with large datasets? Alternatively, is there a recommended way to pass global/environment variables dynamically in the Bruno CLI?

Thanks a lot in advance!

📝 Steps to reproduce

Use large collection with many folders and subfolders
Use large environment

📁 Collection to reproduce

No response

📷 Screenshots/Live demo link

Screen.Recording.2026-08-10.at.22.48.42.mov

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• Collection environment editor (grid) is slow #8142

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Rohan-Bruno]

Hi @stickpin, could you enable the File Cache beta feature by going to Preferences → Cache → File Cache and let us know if you notice any improvement in performance?

Your feedback on the File Cache feature will help us evaluate whether these changes address the issue.

[stickpin]

Hi @Rohan-Bruno,

I've enabled the file cache, but unfortunately, it doesn't change much. :(

I also see in MacOS Activity Monitor a high CPU load once I am scrolling the environment or trying to type something.

Please let me know if you have any other ideas or if you want me to try a beta/dev release.

Thanks a lot for your help!

[Rohan-Bruno]

Hi @stickpin, since it caches parsed files, the first load of a collection may still be slow. Loads should be noticeably faster from the second time onward.

You can also try our nightly builds to check if you see any difference in the performance with large collection variables - https://github.com/usebruno/bruno-nightly-builds/releases

[stickpin]

Hi @Rohan-Bruno,

The same issue with v4.1.0-2026.08.10.
I've made one more video to show you the performance difference between the Collection and Global environments.
In the Collection environment, it took a few seconds for the "testtesttest" that I was typing to appear; in Global, it appears as I type.

Screen.Recording.2026-08-11.at.11.54.50.mov

[stickpin]

@Rohan-Bruno, just want to let you know. I was looking into existing PRs and found one that resolves the performance issue.
I've compiled the version with this fix: #8931
Now the collection environment works as expected:

Screen.Recording.2026-08-12.at.07.52.26.mov

[Rohan-Bruno]

Hi @stickpin, thank you for the details!

We've shared these findings with our engineering team for further investigation. We'll keep you posted once we have an update.

[stickpin]

Hi @anusree-bruno, @sachin-thakur-bruno, @Rohan-Bruno,

Would it be possible to get a pre-release or experimental build with the performance fixes?
We're currently migrating from Postman, and this bug is creating a major bottleneck for us.
Sorry for pushing...

Thanks a lot in advance! :)

[anusree-bruno]

Hi @stickpin, thanks for checking with us. PR #8888 is currently under review, and we’re targeting it for our v4.3.0 release, planned for the end of October.

We should be able to share an experimental build by the end of this week, but I’d recommend waiting for the release if possible, since experimental builds may be less stable.

[stickpin]

Thanks a lot, @anusree-bruno! :)

I will wait for the experimental build and share feedback.
I have relatively large collections and environments (with env and runtime vars), with many complex test scripts, and now, thanks to Bruno, external JS files that are imported into running flows. So it could be a good beta-testing environment, at least for the stuff that I use.

[stickpin]

Hi @anusree-bruno,
Sorry to bother you again...
But is there any chance you can share the build with the fix?

Thanks a lot in advance!