I just opened my laptop for the morning coffee :coffee: to this little beauty. [CleanShot 2026-01-08 at 06.34.01@2x] I’m no stranger to 4 - 5 GB usage, but this is odd. Most of the times when it reaches 4 GB the editor starts weirding out and then crashes. Any one else experiencing things like this? You guys got some solutions? I’ve tried lots of stuff and nothing helps. This is on Brave with “run checks on backend workflows” on, but I’ve tried: on all the browsers: Chrome, a ton of Chromium-based browsers, Firefox, Safari, hell, even Edge. all the shields up of Brave. turning on/off the “run checks on backend workflows” “optimizing application” multiple times constantly deleting reusables – I’ve got a sneaking suspicion there’s something in the app’s JSON that triggers the editor to go into an infinite loop.

[image] georgecollier: References like “Parent group’s thing” are unnecessary Is each instance generating and/or running a JS function over and over again?

Any expression evaluation incurs complexity (our abstraction which deals approximately with compute)

[image] georgecollier: References like “Parent group’s thing” are unnecessary. It’s generally used to pass data down groups, but any situation where you DO use that, you can also just reference the element directory, avoiding chain of parent group’s X that serves no purpose other than to get data from a superparent to a child, and adds compute intensity to evaluate all of those expressions. I was just evaluating the pros and cons of this in my head over the last few days as I rushed through a new module that became a lot more complex than I expected. Good to hear it from someone who works closely with the Bubble team.

[image] georgecollier: References like “Parent group’s thing” are unnecessary. It’s generally used to pass data down groups, but any situation where you DO use that, you can also just reference the element directory I feel like this isn’t true or else I wouldn’t do it, but I’ll take your word for it.

[image] randomanon: I feel like this isn’t true or else I wouldn’t do it, but I’ll take your word for it. It is :smiley: If you’re referencing Parent group’s thing, you can logically just reference whatever Parent group’s Thing is referencing (or whatever THAT is referencing, right up to the original datasource that’s not using Parent group’s thing). This is true for every case (though will happily be disproven by a counterexample :wink: ) Arbitrary example └─ Group ProductSection (Type: Product) ├─ var - Product: Selected Product ├─ Text Title │ └─ Dynamic text: var - Product's name ├─ Image Hero │ └─ Dynamic image: var - Product's hero_image ├─ Group PriceAndCTA (no data source) │ ├─ Text Price │ │ └─ Dynamic text: var - Product's price:formatted as currency │ └─ Button Add to Cart │ └─ Workflow action: Add item → var - Product ├─ Group Details (no data source) │ ├─ Text Description │ │ └─ Dynamic text: var - Product's description │ └─ Group SellerInfo (no data source) │ ├─ Text Seller Name │ │ └─ Dynamic text: var - Product's seller's name │ └─ Button View Seller │ └─ Navigate to Seller page │ └─ Data to send: var - Product's seller └─ RepeatingGroup Reviews (Type: Review; Data source: var - Product's reviews) └─ Cell ├─ Text Review Body │ └─ Dynamic text: Current cell's Review's body └─ Text Reviewer └─ Dynamic text: Current cell's Review's author's name

[image] randomanon: I feel like this isn’t true or else I wouldn’t do it You should have stopped in September of 2024 [image] Do Not Overuse Parent Groups Thing Tips I made this mistake when I first got started. For the past 5 years now, I’ve been avoiding the overuse/abuse of the ‘parent groups’ thing to pass values down to other child elements when it is for the most part completely unnecessary now. If you are working on a page set to content type you can always just reference the pages ‘current thing’ or if on a reusable element that you set as a type of content reference the reusable elements ‘thing’ instead of the ‘parent group’s thing’. Why have I n…

[image] georgecollier: you can also just reference the element directory, avoiding chain of parent group’s X that serves no purpose other than to get data from a superparent to a child, and adds compute intensity to evaluate all of those expressions. To be clear this isn’t gonna be a huge of client side performance issues in anyone’s apps Like if you got rid of 10,000 of those references, the performance improvement probably wouldn’t exceed the error bars of however you’re measurning it But it stands that in aggregate, we want expresisons to be simple (which parent group’s thing is) and use them only where necessary. For maintainability, if not for anything else, as @boston85719 points out

[image] georgecollier: Like if you got rid of 10,000 of those references, the performance improvement probably wouldn’t exceed the error bars of however you’re measurning it Hey @georgecollier , just curious on your post - are these casuing meaningful impact in how you’re measuring it in the Editor/Client? Or any other golden nuggets you’d like to share? Also, more related to this post, I’m having to refresh the editor on larger apps that I’m working on - especially post merge.

[image] georgecollier: This is true for every case (though will happily be disproven by a counterexample :wink: ) I 100% believe you, I just remember there was a case where parent groups were necessary in the context of a repeating group but it could be a GPT hallucination.

[image] randomanon: , I just remember there was a case where parent groups were necessary in the context of a repeating group but it could be a GPT hallucination. Likely GPT not knowing all tricks. Inside RG can still reference another group. I put one group called Selector then inside it I add other group tied to an option set. When parent group option set is listed as hide, it’s not visible, but whenever I need data or reference to the cells actual data I reference the group Selector. Been doing it for years, you’ve probably seen I’ve mentioned it before.

Editor high memory usage - 14.2 GB (new personal best)

Need help

boston85719 January 8, 2026, 3:11pm 23

You should have stopped in September of 2024

Topic		Replies	Views
Is The Editor Slowing Down For Everyone, Or Is It Just Me? Need help	59	3485	June 23, 2020
Heavy bubble editor Tips	4	180	May 29, 2025
SLOW SLOW SLOW please reassure us! Questions	23	2954	December 30, 2017
Bubble editor is so slow, unworkable :( Database	87	10879	July 10, 2023
[early access] Help us test Bubble’s editor performance improvements Announcements	90	5568	January 1, 2025

Editor high memory usage - 14.2 GB (new personal best)

Related topics