Fun Data! that ultimately proves

nothing!.. yet?..

I got a bit side tracked on some performance speculations. I thought maybe some others here might enjoy. (If you have some insights, please do add).

Performance is a reoccurring debate here on the forum. I’m just as guilty in seeking a “definitive answer.” But because apps are so different; there really is no one size fits all answer.

This data should not be perceived as an answer, but rather a “situation”

So here is the situation!

  • I want to count a Boolean value (yes/no) on a list of data base things.
    (how many are = yes?)
  • The things are attached to the user.

(the way this example is set up I have a list of things stored on the user datatype)
(an alternative which has been mentioned on the forum would be to store the things in a separate table and instead attach a user to those things - which does appear to be more scalable in the right instances)

I can do two things:

  1. do a search for things (constrain the search)
  2. filter a list of things (that are attached to a thing)

Here is the data. (Right click and select open image in new tab - to view the larger image)

(quick note: I only half know what I’m looking at here, I’m not 100% sure how to effectively understand the implications of why requests & transferred show two numbers (and with such variance between methods)

So here is my analysis:
a) Do a search does less requests (good?)

B) Total Load time (8 page refreshes)
(represented as a total, not an average / also I had 8 data (the picture only shows 7)
Search total load time = 42.39 Seconds
Filter total load time = 40.37 Interesting…

C) Total Finish time
Search = 231 Seconds
Filter = 182.64 Seconds

D) Transferred (overall doing a search appears to transfer less (assuming that’s a win?); however just for the hell of speculating, I represent it as a % instead: which led to an interesting outcome of which I don’t quite understand:
1st item = 28% transfer rate
item with largest load = 17% transfer

1st item = 4% Transfer
Largest load = 10%

And finally!

E) Resources (which looks like a win for search)
Search = 5.7MB
Filter = 6.9MB

Now keep in mind, the things that I am searching through are attached to the user data type. So does that mean that the search function already knows to search those data items, since there already attached to the thing?

  • that would be fast for search
  • but could cause some serious performance problems if you have 1000> items attached to the user, not because of the search but because you are seemingly loading some portion of all those items, everytime your reference the parent (such as a user, on a user profile page)
  • notice how the Filter resources were larger than the search resources? That will likely prove to be a substantial exponential trend. Resources will go very high! if you have a large list of data things stored on another data type.

However if the search function does not know that the things to search are attached to the user - then it would default to searching the relevant data table.

  • this is presumably much more scalable especially if Bubble does really have indexes that can very quickly find a list of 100 items in a datatable of 10M, if the search query uses the current user/user as a cross reference.

So, if I have any conclusion at all it might be something like this:

  • in some instances, filtering can very much be an effective performance option. In fact better, than doing a search (depending on your database design). But filtering will crumble at the seams in larger/high scale instances.
  • If bubbles do a search function, can do a search on a list of things, that are attached to the user. That sounds pretty sweet. Meaning that the search narrows a query down to 100 items (even though those 100 items are in a larger database of millions), without having to traverse millions of data records.
  • In instances of very large scale and large database items you will most certainly want to construct a data model that resembles something like the one shared on this post:
    Alternative approach to the Bubble’s recent tutorials for list of things

So ya. If anyone has anything to add. Great. If not - that’s ok, hopefully a fun read.
Like I said it is not a definitive answer; in fact the overall answer is still notoriously vague.
But that is partially what we get when we decided to build on… “Another Layer of Abstraction” (as I recall bubble once calling it). Bubble is still a genius product and great fun, even if it is a bit elusive at times. So a big thank you to all that work on growing and maintaining Bubble. And hope everyone is doing alright in these unusual covid times. It’s seeming to be quite a transformative experience for society, but ultimately it will lead to better systems.

Hopefully my writing is comprehensible; and not some impulsive rambling madness.
I’m half confusing myself as I write all this

1 Like