Improvement in implementation of “:count is 0”

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].”

georgecollier · 2024-09-12T18:09:52.929Z

samnichols:

Have you done this with “first item is empty

Do a search:first item = 0.3 WU because it’s a search that attempts to return Things

Count is {positive integer} = 0.2 WU as it’s an aggregate query

TipLister · 2024-09-12T18:45:38.892Z

great job for listening to feedback again. keep it coming!

adamhholmes · 2024-09-12T18:49:54.921Z

samnichols:

Curious if it’s as efficient as “count is [positive integer].”

It’s not… it’s ALWAYS at least 50% more costly in WU, and in some cases a lot more - in my original tests, discussed in one of the linked threads, first item is empty cost over 11 times more WU than count < 1 (but that will always be dependant on the data size).

(it doesn’t have to be a positive integer by the way… any number other than 0, positive or negative, integer or decimal… the issue is specific to the literal value of 0).

WU cost aside… there is an argument to be made that first item is empty (despite costing 50% more in WU) is actually faster than count < 1 (Bubble support have been fairly adamant about this when I’ve discussed it with them).

But in my own testing I’ve never observed that to be true. I’ve tested this with a few hundred thousand items - maybe with a few million it might be different - but in all of my own testing using the count not only costs less, but is faster as well.