I think that second search in the conditionality of method one might be the culprit.
So it’s hard to make general comments on this kind of thing because a) it depends on the shape of your data, and b) we’re constantly changing how things work behind the scenes to try to make things faster, but a few thoughts:
-When you have a list stored on an item, that list is loaded whenever that item is loaded. This is bad if it’s a really huge list, because it means fetching that item is slow. But, it means that if it’s a short list, retrieving items on the list is much faster, because they are already loaded. I think this is probably why @potentialthings saw a speed improvement. The general rule is if you expect things to scale to large numbers, it’s better to use a reference and do a search for, but if you know it’s going to be fairly limited, it’s faster to store it on a list.
-However, we are probably going to change this at some point: the current behavior of loading the entire list when you load an item is one of our current scaling limitations, since it means that there’s no way of making infinitely scalable many-to-many relationships. So, it’s on our list of things to change.
-When testing these kinds of things, it’s very important to have an isolated test page that just has the search on it. On a big page, if there’s a bunch of data all being loaded at once, sometimes the thing you’re looking at might actually be fast, but it’s getting queued behind slow stuff, so you’ll end up looking at the wrong culprit.
-When you first create a new search that you haven’t done in your app before, and you have a lot of data, it will run slow at first, then speed up after a while, because we have code that looks for big searches and automatically builds database indexes to optimize them. So keep that in mind too 
-I’m always interested in cases where a) you have a search that doesn’t fetch that much data, but b) it’s taking a long time, because that generally means there is room for a performance optimization. There are some known issues here, like :unique tends to be much slower than it ought to be (we have a project underway to change that), but often if you can isolate a search on a test page and show it to us, we can find something to tweak to make it faster.
11 Likes
Bam! Thanks for the response. I’ll stop spreading nonsense now
Thanks for the explanation I really appreciate that.
But when is it going to be faster because right now the page that loads the repeating has just a header, a button and the repeating group list with more than 200 items and I can´t figure out how to make it faster since the latest conversations.
And the problem is that the users are complaining about that frequently.
Are you going to fix this soon? It would be so nice.
Thanks a lot @josh for taking the time to explain this.
Bests.
Many thanks for this explanation. Curious about this though…
Is there a sweet spot (number) here to know which might be better?
Example if I have a data Event and a List of Attendees is expected to be 50 Attendees, but if some events have 100’s of attendees then I would need to reference, or is it more like 1,000’s?
Also, this makes me realize that I have been adding a List of Contacts (for a basic CRM) to a User’s Company, which based on what I read here will not scale well at all
When you guys say reference, what do you actually mean?
Instead of:
[thing]Event
Attendees - List of Attendees
You would have:
[thing]Attendees
Event - Event
When searching for Attendees you would then ‘do a search for Attendees’ with the event as the constraint?
Any update about this improvement on performance @emmanuel ?
We need to know since we´ve to make an important decision based on that.
Thanks a lot.
Correct @vincent56.
I am curious if there is a point when it is best do it this way, as I currently have a List of Attendees for an Event, but if I work with large events, then maybe the other way is more efficient. Was hoping to get some other feedback on this, as it is what @josh suggested when things scale to ‘large numbers’, just not sure when to judge what large numbers actually are (hundreds, thousands, etc)
I would like to know the same thing. I have ‘Inventory’ with ‘List of items’ which are hundreds of items and in the backend the database for Inventories loads really slow because it has to load all ‘Items’ that are connected to the Inventory.
I also need to add all items to the inventory as a separate step…
Kind of a mess here I think. What I´ve heard is that “do a search for …” is the fastest way but the problem is that Bubble´s performance is really really slow when showing the repeating groups. We´re really worried about this because we´re having a lot of complaints about this slowness.
I rather have performance improvements and more polished plugins than new ones.
I do think that they should focus more on this since once you start using Bubble you´re like “wow this is amazing you can do everything” but by the time you have created something you consider a good project then you discover that this kind of things are the ones that makes the project not that great. Speed on everything is critical and also a basic one.
Bubble attracts you in the first time but in my particular case is getting hard to keep me.
We’re working on database optimization right now (which includes grouping data for charts) but this is not a small project. We’re hoping to be done in a month or so.
6 Likes
I understand it´s a big project but it´s causing a lot of troubles.
Will it be possible to have a date or at least a week? We´re having hard time keeping our users based on this particular issue.
At least if we have a date we could tell them that it will be solved soon.
Please.
Thanks a lot @emmanuel
It’s our number 1 project. I won’t give a date as we can’t be sure we’ll deliver in time. But should be before may.
Other users apparently don’t have the same problems as you have regarding speed, so there are some design choices you’ve made that make this more of an issue for you currently. I recommend you try to find different approaches for the time being.
@ryanck you might find it worth sharing some specific details of the searches that take a long time, some people here have experience at data search optimisation.
1 Like
I´ve worked with some of the top Bubble certified partners and for the time being they said that there is no other optimization that I can do.
I´m just showing a list of invoices of the user so “do a search for” is the way to go since it also has constraints.
We have tried the same database in Knack (https://www.knack.com/) and it´s extremely faster than Bubble right now.
Thanks anyway.
I´m pretty positive about the performance improvement @emmanuel and their team are doing. So we look forward to it.
That is an interesting idea. You could host the tables in an outside database and use either APIs or the Database Connector Plugin to read them.
Sacrificing simplicity for speed might be appropriate.
Hi !
Nicework !
I am really currious on how you implemented your “view Printable report” page. Could you tell me how you did it ?