Improvement in implementation of “:count is 0”

artemzheg · 2024-09-12T14:35:45.825Z

Just to be sure, is this fixed with :count is 0 improvement?

Search: count is 0? Or Search:first item is empty? Tips

So, since the change in pricing model, and the introduction of WUs, I’ve spent a LOT of time (probably way more than it’s worth) testing many, many things in Bubble to establish the most WU efficient ways of doing standard (and not so standard) things, especially in relation to loading related data (lists versus no list etc.) and bulk data processing. I’ve been tempted to publish my findings so far, for the benefit of others, but I’ve held back as I’m yet to be convinced that it’s actually a wo…

boston85719 · 2024-09-12T14:36:23.560Z

I want to be able to return less data from the database.

Jici · 2024-09-12T14:36:44.959Z

So just to be sure I understand correctly, this will always perform a msearch request but return less data or it’s now performing a maggregate request?

Good news by the way

georgecollier · 2024-09-12T14:48:25.097Z

This would be big if true. Unfortunately, it seems that Do a search:count is 0 still performs a search request, not an aggregate request, despite :count being an aggregate query. Even if it doesn’t return things from the DB (as would be expected from a :count), it still costs more WU, and that seems to be an error on Bubble’s side.

The simple case of an unconstrained Do a search for Things:count is 0 should always cost only 0.2 WU (cost for an aggregate search), and should have no Things returned from the DB.

However, I can see from the network tab that it still performs a search, which costs 0.3 WU.

Meanwhile, if I do :count is (any positive integer), it does an aggregate request and costs 0.2 WU.

There’s still clearly a difference between :count is 0 and :count is {positive integer}.

:count is 0 costs 0.3 WU and :count is {positive integer} costs 0.2 WU.

Why?

Edit: adding images

CleanShot 2024-09-12 at 17.07.16@2x812×766 19.1 KB

CleanShot 2024-09-12 at 17.11.04@2x806×786 18.8 KB

adamhholmes · 2024-09-12T15:11:47.053Z

Jici:

So just to be sure I understand correctly, this will always perform a msearch request but return less data or it’s now performing a maggregate request?

Seemingly, it’s the former… it still performs an msearch (for some reason), but rather than returning the full data of the first 10 items (which is what it always did before in my testing), it now only retrieves the first item, and only the Unique ID of that item. So, depending on the size of the data it may well be a lot less data.

But that means it still costs 0.3 WU instead of 0.2 - which is still 50% more than it should be, and still 50% more than using the number 1 instead of the number 0.

georgecollier:

Meanwhile, if I do :count is (any positive integer), it does an aggregate request and costs 0.2 WU.

There’s still clearly a difference between :count is 0 and :count is {positive integer}.

:count is 0 first costs 0.3 WU and :count is {positive integer} costs 0.2 WU.

Why?

It’s even more specific than that, in that it’s the number 0, only as a literal value that causes the problem.

If it’s a variable (i.e. a custom state) it works fine and just performs an agg search.

bek:

To confirm, “:count is 0” should now be the go to for checking if a list is empty, is that correct?

Nope…

Even with this ‘fix’ count is 0 still costs exactly 50% more in WU than count < 1

georgecollier · 2024-09-12T15:13:32.390Z

adamhholmes:

If it’s a variable (i.e. a custom state) it works fine and just performs an agg search.

brb, creating ‘var - 0’ in every application
CleanShot 2024-09-12 at 17.12.53@2x

Just tested, and you’re still correct, Search for Things:count is var - 0's number does an aggregate search!

jefeoliveira22 · 2024-09-12T15:23:56.700Z

Why is the community explanation better than a Bubble employee?

which should be a minor boost to performance and also a reduction in workload.

What kind of announcement is that?

ahmed.elkaffas · 2024-09-12T15:30:55.843Z

I have read a lot about the difference between “count is 0” & “first item:is empty” and of course I am using the latter almost everywhere to check for a value.
The community responses show that we shouldn’t yet use “count is 0” so I won’t change anything for now until further announcement !

adamhholmes · 2024-09-12T15:47:09.740Z

ahmed.elkaffas:

The community responses show that we shouldn’t yet use “count is 0” so I won’t change anything for now until further announcement !

True this fix offers only a slight improvement when using count is 0, but using count < 1 is still better than first item is empty (in some cases significantly).

Using first item is empty:

In cases where the first item is empty (i.e. there are no existing items in the database), it costs 0.3 WU for the search.

In cases where the first item is not empty (i.e. there is an existing item in the database) it will cost 0.3WU for the search, 0.015WU to retrieve the first item, plus however many WU it costs for the amount of data retrieved.

Using count < 1 will only ever cost 0.2WU.

Jici · 2024-09-12T15:47:42.253Z

Other options: count < 1 will do a maggregate search and cost less WU (var options is also possible like @adamhholmes) . When you need greater than 0, you should also use >= 1 instead

brenton.strine · 2024-09-12T15:48:29.219Z

ahmed.elkaffas:

I have read a lot about the difference between “count is 0” & “first item:is empty” and of course I am using the latter almost everywhere to check for a value.

Actually the best practice till now has been :count <1 rather than :first item is empty (see https://x.com/brentonstrine/status/1819054939911434714)

With this announcement, it seems :count is 0 is now actually better than :first item is empty but still not as good as :count<1

fede.bubble · 2024-09-12T16:04:56.451Z

I see this as more of a quick win the team was able to put together outside of their roadmaps than a “fix”. It’s better than before, maybe not perfect, but better.
As always, I’ll keep passing everyone’s feedback to team so we can keep getting better

brenton.strine · 2024-09-12T16:10:40.762Z

This is

fede.bubble:

I see this as more of a quick win the team was able to put together outside of their roadmaps than a “fix”. It’s better than before, maybe not perfect, but better.
As always, I’ll keep passing everyone’s feedback to team so we can keep getting better

This is a huge win for all the apps out there built with :count is 0. In fact this is now even better than :first item is empty so that’s great news!

This meme isn’t quite accurate just yet… but some day it will be!

image880×1240 91.3 KB

adamhholmes · 2024-09-12T16:12:29.886Z

fede.bubble:

I see this as more of a quick win the team was able to put together

Quick?.. it only took 15 months!

But yes… it is an improvement

ahmed.elkaffas · 2024-09-12T16:25:38.212Z

Thanks all for your detailed responses !

fede.bubble · 2024-09-12T17:28:45.208Z

adamhholmes:

Quick?.. it only took 15 months!

From my point of reference when I started asking about it internally

brenton.strine · 2024-09-12T17:45:29.893Z

adamhholmes:

Quick?.. it only took 15 months!

I think what this shows is that Bubble has put into place better processes to capture and handle issues like this… and it’s working! We now have the Bubble Ambassadors, and Fede and we have much better ability now to bend the ears of Bubble engineering leadership for things.

I’m a Bubble Ambassador and I started making noise about this again on August 1st–both in internal channels and publicly. With the new processes in place it only took 1 month 12 days. That’s actually a remarkable turnaround time! Consider all the steps Bubble had to go through

Receive the feedback
Filter it and recognize it as an important thing that needs to be fixed
Prioritize it against other priorities
Schedule engineering time, reallocate resources.
Come up with a plan to fix it.
Engineers actually fix it.
Test & Deploy

It’s actually a remarkably fast turnaround time.

Jici · 2024-09-12T18:02:58.343Z

brenton.strine:

Prioritize it against other priorities

We shouldn’t have to ask for this kind of stuff to be priorities. THEY ARE. Everything related to WU improvement should have been done a lot more time ago. We started to see improvement probably around June with the SAWOL update. But a lot of requests was already created (and answered by @josh) when the WU pricing was released. This one about 0 issue was raised a lot of time ago and known from team. Returning only fields needed in search was requested a lot of time and never implemented even if @josh agree to this. We get some updates on logs and charts a week ago. And even so, we are far from what we could expect to manage WU and optimize them.

From my point of view, for 1 year, the top priorities should have been: stability, and WU improvement

And I hope they don’t consider this actually fixed…

brenton.strine · 2024-09-12T18:07:40.406Z

I think ever Bubbler has their own list of what they consider to be the highest priority items, and I guarantee you that they’re all different. And internally they’re also working to advance Bubble with new features plus fix issues that we have no idea about at all.

It’s actually a monumental task to take in all the various competing needs and opinions and find the most impactful stuff to work on. In fact, if you’re up for this kind of work, it would actually be really helpful!

I’ve never been at any company that gets it 100% right, but I do feel that Bubble is better at it now then they were 1 year ago.

samnichols · 2024-09-12T18:08:57.296Z

Have you done this with “first item is empty”? We use that one primarily. Curious if it’s as efficient as “count is [positive integer].”