We’re excited to share an improvement to the implementation of how the “:count is 0” operator in a dynamic expression works. Behind the scenes, we’ve changed how we implement “:count is 0” so that it returns only the data it needs to check if the count of items is empty, which should be a minor boost to performance and also a reduction in workload.
Specifically, this implementation improvement will reduce the workload used by “:count is 0” because it will return less data from the database (one of the activity types in the workload formula). It will reduce workload more in situations where the individual things of a data type being counted tend to contain more data and thus are bigger in size; returning less data from the database means the total size of the data returned is smaller. The workload formula remains the same, but “:count is 0” will use this activity type less intensively.
Thank you to the users who have shared this feedback!
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?
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.
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.
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.
Nope…
Even with this ‘fix’ count is 0 still costs exactly 50% more in WU than count < 1
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 !
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.
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
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
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
