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

[randomanon]

@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.

[georgecollier]

@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

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 )

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

[boston85719]

@randomanon

I feel like this isn’t true or else I wouldn’t do it

You should have stopped in September of 2024

Do Not Overuse Parent Groups Thing

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…

[georgecollier]

@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

[DjackLowCode]

@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.

[randomanon]

@georgecollier

This is true for every case (though will happily be disproven by a counterexample )

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.

[boston85719]

@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.

[georgecollier]

Yeah the only time you can’t access a group is if the the group you want to reference is a child of a repeating group from the place you’re trying to reference; but parent group’s thing doesn’t solve it.

[randomanon]

@boston85719

Likely GPT not knowing all tricks.

I was referring to my own brain.

[rico.trevisan]

Quick update:

• Using Firefox in private mode has helped.
• creating a branch seems to be the problem
• even in Firefox, the memory will increase, it will eat up CPU, and never let go
• so, yes, now it’s always create branch → duplicate tab → close the previous one

[code-escapee]

If you mean regular Firefox, try Firefox DEVELOPER

[DjackLowCode]

@code-escapee - what’s the benefit of Firefox for Developers? I had heard I could unlimit a tab’s Memory usage but couldn’t get it to work.

[code-escapee]

I don’t think it “unlimits” memory, and I’m not a browser expert (or even close). This is just based on what I see in practice.

I first saw Firefox Developer Edition suggested on the Bubble forum, tried it, and haven’t really gone back. For big, JS-heavy apps like the editor, it just feels faster and more stable. It seems less aggressive about throttling, DevTools interfere less, and Firefox Dev seems to handle memory leaks more gracefully.

One caveat: it’s not perfect. A couple of common editor actions still work better elsewhere for me, like merging branches or copying elements between apps, so I switch (back to Chrome) when needed.

[NexradJosh]

@rico.trevisan

I believe that is called a memory leak.

Indeed

[rico.trevisan]

So the new update of the editor seems to have cleaned up a few things. First time in months that the editor registers below 1 GB in Firefox.

In Brave, it’s hovering between 1.5 and 2 GB.

[rico.trevisan]

Ooops, I take that back.