:count | Does it lag an app?

I’ve heard that :count can really bog down an app. Is there any validity to this statement? I’m looking to use it in order to simply display, in a text box, the count of a filtered selection of data. I’d be doing this in a few different places in the app, but the area I’m primarily using it would be on a popup, with a maximum of 4 :counts running at once on a visible group inside of the popup to display this information, as well as a couple more in separate groups which will not be visible at the same time as each other or the primary 4 :count group.

Would this lag my app? Am I better off creating a field for a pre-existing data type which would track this number so I wouldn’t have to use :count? I noticed it acting a bit odd during multi-user testing on Wednesday (the page would sometimes need to be refreshed before it would show the accurate count), and I figured I’d check around in the forums to see if this could be the issue, or if it was just a temporary glitch on Bubble’s side.

Thanks in advance!

-Collin F.

Edit: I should clarify, the numbers it would be displaying would be relatively low, likely only counting 5 different entries of data at a time due to it filtering for specific details.

1 Like

What create a lag is fetching data, not count itself. To be able to : count, Bubble need to fetch data (and all the payload). So this can create a lag before displaying count.

So if I’m looking for a fairly limited range of data (the app will search for entries in which the field matched up with the field being looked for in the popup) of under 10 entries, :count would not affect this in terms of lag?

I don’t think. Is your Thing DB big? If yes. Search constraint will be important to reduce loading time. Because even if you fetch 10 items, but your DB is large, this can create lag. if you use :filtered instead of filter in the search, this will also create lag because filtered is applied after the search have been performed

It is filtered during the search. Would creating a new field on the data entry that would track this number be faster?

At the moment, it’s set up to where a user can create several sub-profiles, each being a sort of alternate identity. Another user can then create a separate data entry (we’ll just call it a report). One of the fields for this report is the recipient of it, which the secondary user sets as one of the various sub-profiles that others have created. Then, when any user views the sub-profile, it shows a :count of all reports attached to the sub-profile by searching for reports with the displayed sub-profile as the recipient. There are 4 different kinds of these reports, hence the 4 different :counts that I mentioned earlier. Would it be more efficient to simply add fields dedicated counting these reports onto the sub-profile data so I don’t have to do any additional searches, or is that not worth it for what little lag it may expel? Sorry if this sounds confusing. It’s a specific type of app that has a lot of specific jargon to go with it, so I’m doing my best to explain it with terms more general to bubble.

Also, the DB is moderately sized at the moment, with a couple hundred things, but I imagine that the things will likely add up pretty quickly as the user base grows.

Yes it will be faster to create a field (to fetch the info) but you may loose somewhere else depending of your setting (if you just add +1 or remove -1 whena dding deleting item, it’s fine, but if yu redo the same Do a search:count, the workflow will need to fetch data.

Now my main question is: is your DB correctly set? What I mean is can you avoid search and use linked data instead?
Example: Current user have a field that point to subuser. It’s easy to use Current user subuser:count. This is the kind of action that will help a lot your app to go faster :wink:
Sometimes user set a field in subuser that point to user, and this will requiere you to use a Do a search. it will be slower.

Thanks, that pretty much solves it for me. With that in mind, I believe I’ll be linking the reports to the subusers as opposed to relying the other way around in order to retrieve data. Being as the app already has to fetch the subuser data for the rest of the popup, I think this will be optimal for me. Thanks again for your help!

1 Like