Bubble is definitely overcharging us for WUs

Thanks so much @boston85719 for the detailed reply. Your detailed response and discussion with @georgecollier motivated me to do some investigation myself too. Here’s summary of my observations with respect to how many searches are done in various conditions.

One surprise one is first one where two searches are being done if RG is showing all elements.

Please note I only analysed the “invisible” scenario, not the “hidden” one.

Also, I only looked at number of searches and not the WUs in itself.

Hope this summary helps others. I think this RG thing deserves a separate thread by itself. Lot of scattered information at different places.

3 Likes

Easier to parse version of the above, courtesy of Claude:|

1 Like

Isn’t this all exactly as we’d expect then?

To summarise:

  • if RG cells aren’t visible, no search is made
  • limiting to one cell will return less items
  • using :count will run an aggregate search
1 Like

No big surprises, just didn’t want anyone to bash their heads into the wall trying to parse that table.

1 Like

:grinning: Thanks for converting it into that kind of table. I had thought of making the table like that. But I felt conflicted on whether that would be more readable or not. But as you have demonstrated, it is more readable that way.

Yeah not many surprises, but I still wanted to summarise what I observed as otherwise question keeps popping in head and information around it is cluttered.

One surprise is there though:

  • That if an RG is present with all elements visible, two searches are done. One for first element and one for all the elements. This is irrespective of whether RG data source is being used elsewhere. To me this is a bug actually.
  • Also, one good thing is that if RG is invisible and I use its count somewhere, it still runs only the aggregate search for count and RG’s data query is not run. That is good as I do not have to write search for.. at two places.
  • Using RG's element:count is no longer a surprise because you had already discovered it, but it is nevertheless a surprise (and bit unfair) in my view.

This is a very constructive discussion , my contribution to these is this ,

Docs or tutorials thought us that conditions are read from left to right , if former one doesn’t fit than latter one doesn’t execute . That is not the case for rg:count operations.

condition : X’is visible and rg:count>0 , data source is yes . Even X’is not visible it will run the count operation.

Wow, this is big as well. I rely on this so many times.

p

If Group A is not visible, then Search for Products will not run (good)

The same applies for the count, contrary to what you say. On a simple page where:

  • Group A is invisible always
  • Repeating Group Product is invisible always and has a data source set

The expression Group A is visible and Repeating Group Product’s List of Products:count > 1 will:

  • not run any searches
  • this because Group A is invisible
  • the second part does not need to run is it becomes impossible for the expression to be true

So, this is all good behaviour (albeit in these two test cases) that is in line with the docs.

1 Like

I just want to add something to the meta discussion here. This may have been said elsewhere a million times but I’ll add it anyways.

I believe the WU are fuzzy in order to obfuscate the real cost. It’s much harder, if not impossible to determine the true cost of your app at a glance (meaning without crawling through documentation). Imagine trying to calculate what your app would cost before development. Nearly impossible.

If bubble used traditional metrics that are used to measure usage such as number of requests, processing time or something else that was standard it would be so much easier. Bubble does stand to benefit from a fuzzy WU system since their real margins are hidden to the consumer and the real cost is also hidden until after your app is built. Whether intentional or not isn’t the question, it’s just a matter of fact.

1 Like

The WU is fuzzy because they have very primitive unscalable architecture that runs everything in a giant swamp. They can’t actually drill down into those specific metrics even if they wanted to on a per app basis. This is why they have to use crude statistical methods to find correlations between Bubble events and performance costs.

It is not by design, it is not by choice, it is by necessity.

The main problem is that the statistics themselves are poorly done, they did not involve a real data scientist during the process. @aaronsheldon is a stats guy and broke down why the methods they were using were inappropriate but it mostly landed on deaf ears. He doesn’t post here anymore btw.

1 Like

I read your ss incorrectly , if you say second condition doesn’t run the count operation, then it is a question of

  1. Did they tweak it from 3 months ago
  2. Complexity of the page (I have an SPA)

The work around is have a seperate group that has the value of number , and when X is visible do a search for :count as a value , Than use that value like X’is visible and group number’s number > 0

In my view, Bubble will become a front end platform. As much as they insist that we use their backend, besides being expensive, the performance is terrible.

If that were the case they’d be the worst out there :rofl:

This is an area they want to focus on in the next year… and from what I can tell, they mean it for real this time.

In the 2023 bubble con they made a lot of promisses about performance improvements, and I didn’t see any improvment this year (2024). Based on their behavior on no follow their promisses. Unfortunately I don’t expect any significant improvements.

1 Like

Unfortunately this is true, since 2023 Bubblecon any tangible performance related improvement has been the more defined road map. I don’t expect too , at least any time soon.

1 Like

Isn’t this like a bug? Can you please reach out to Support with your findings and understand what’s going on?

Nah, Im good