So some overall guidelines. Note that these kinds of guidelines definitely have a sell-by date, since we’re always trying to optimize slow stuff, but here are some of the big performance levers:
-
The more data a search fetches, the longer it takes. That probably sounds pretty basic, but we routinely see pages that fetch thousands of data items on page load. Or, we sometimes see searches that only fetch a few things – but each thing has KBs or MBs of text data stored in its field.
-
Bubble tries to avoid fetching more than it needs to. So, if you have a search in a repeating group, we only fetch enough data to fill the visible cells in the repeating group, plus some extra as buffer in case the user scrolls. However, there are things that force Bubble to load more data. If you do an additional operation to the results of a search such as filtering the results, we have to load enough data to find stuff that passes that filter… so if you have a 10 cell repeating group, we might have to load 100 items to find 10 that match. If you then get that filtered searches’ :count, we have to load the entire list, because without looking at each item we can’t know the number that passes the filter. Same with sorting – if you have a sort directly in the search, we can do it in the database, but if you do a search, then another operation on the search, then sort the result of that, we have to load all the data to see what sorts lowest.
-
So the general rule is: do as much sorting / filtering in the original search as possible. The more you’re able to shrink the search to begin with, before you start doing various :filtered, :unique, :count, merged with, etc., the less data we’ll need to load. (This is one of the areas that we’re regularly changing, though… we’re trying to move as many operations as possible to the database. For instance, when you do a search and then a :count, with no intervening operations, we don’t need to load all the data to count it – we do that in the database, so it’s much faster to do a search then :count than to do a search, then :unique, then :count )
-
Another thing to keep in mind is that when you use dynamic data such as the result of a search as one of the constraints in a search, we can’t start the second search until we finish the first search, because we don’t know what the correct constraint should be. If the first search only returns a small amount of data, that’s not a big deal, but if it returns a lot of data, and you chain multiple searches together like that, you can create extremely slow pages, because we have to evaluate it all one-at-a-time, instead of in parallel (which is what we normally try to do).
So those are some general guidelines. Think about what data we’d need to fetch to get the answer, and minimize the data. Think about what order things have to happen in, and try to make it so that things can happen in parallel.
Now, to answer some of @blueback09’s specific questions:
“For example, if I have a dozen elements that need to run the same search, is it better to have one hidden element run the search and then have the visible elements reference that hidden element’s value?”
Generally, no. Bubble is smart enough that if two things do the exact same search, it’ll be able to combine them automatically.
"Is there a difference between one action that changes a dozen fields and a dozen actions that change one field? "
Yes. The first one is much faster. We execute each action all at once, then wait for it to finish before executing the next action, so if you have 12 actions, we have to wait 12 times, whereas if you have one action that touches a bunch of fields, we do that all at once.
“Does it matter if a long list of changes are hard-coded into one or more workflows vs iterated over by an API workflow?”
I’m not 100% sure I know what you mean by “hard-coded” here, but I think what you’re asking is, is it better to have a big “change list of things” in one workflow, or kick off a one API workflow per item?
The general rule is, change list of things is fast + good for relatively small (say, 100 items or less) lists. API workflows are a little slower to get through, but they are more scalable and reliable for large lists… if you have a change list of things operating on too big a list, it might time out / fail to finish and break the workflow.
Anyway, everyone please feel free to chime in with follow up or additional questions! I’ll try to check this thread a couple more times over the next week 