# Slow Performance with Repeating Group Filtering **URL:** \ **Category:** Need help\ **Created:** [January 20, 2023, 2:17pm UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513 "2023-01-20T14:17:42Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![umiumansa](https://avatars.discourse-cdn.com/v4/letter/u/ccd318/32.png) [@umiumansa](https://forum.bubble.io/u/umiumansa)\ **Post date:** [January 20, 2023, 2:17pm UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/1 "2023-01-20T14:17:43Z")
Hello, We’ve built a helpdesk system. On the index, the list of tickets are listed in an RG. There are different views available, like “my requests”, or “assigned to me” or “my team’s” each showing different segments of the tickets. There is also a number of filters that are available, to filter tickets by category and so on. ![image](https://us1.discourse-cdn.com/bubble/original/3X/d/d/dd8dfab522dc7d82367e2e7a099f365df8ed9811.png) **Context:** When clicking on a tab to switch view, there are two workflows kicking in: 1. **Reset filters** to default filters for this view: these are stored in a stage on the filter and search bar of the app like so: ![image](https://us1.discourse-cdn.com/bubble/original/3X/9/4/944f04f74314aed62db552fafc477764666f6158.png) ![image](https://us1.discourse-cdn.com/bubble/original/3X/0/4/04d7495b27ee8ab8a4e4cd9a44c5e67431fa685a.png) 2. **Refresh ticket list** : which is basically doing a search of tickets with the filter criteria populated in state at step 1. ![image](https://us1.discourse-cdn.com/bubble/original/3X/f/2/f21fd61ca576ce8a3a9dec2fd91851fe0ff23cd6.png) ![image](https://us1.discourse-cdn.com/bubble/original/3X/8/c/8c25480fe0703f5004413f7c446371276e545b7d.png) You may notice the filter applied at the end, this is to filter by search terms from the search bar. **Problem:** When switching view for the first time after page load, it takes “forever” to load the list of tickets. After switching view the first time, then it’s going at a good pace, which tells me it’s an RG thing at step 2 and not the custom states set in step 1. [Here is a screen cast video to illustrate the painpoint](https://drive.google.com/file/d/1_AJ4QyX0EreSh59niw2USjinOdk66CHV/view?usp=share_link). What’s causing this and what can I do to improve the performance? It’s really bothersome. Thanks in advance for helping. ---
**Author:** ![rico.trevisan](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/rico.trevisan/32/170176_2.png) [@rico.trevisan](https://forum.bubble.io/u/rico.trevisan)\ **Post date:** [January 20, 2023, 2:20pm UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/2 "2023-01-20T14:20:18Z")
I think this technique of chaining criteria together might be what you need. Video from the magical mind of @Andrew.Vernon ---
**Author:** ![umiumansa](https://avatars.discourse-cdn.com/v4/letter/u/ccd318/32.png) [@umiumansa](https://forum.bubble.io/u/umiumansa)\ **Post date:** [January 20, 2023, 2:56pm UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/3 "2023-01-20T14:56:46Z")
Hi, thanks for sharing this video. Did you record it just to reply to this post? 😮 I like your filtering system, especially because it also triggers right when options are selected. However, I’m afraid it is not addressing my issue (unless I am missing something about what you presented). The reason is that the filtering of the ticket list is quick fast and smooth. My issue really is with the view switch at the top, and the **initial load** of the RG. Once the RG is loaded initially, it runs quite fast. There’s something about the first time loading of data that takes more time than usual. ---
**Author:** ![ntabs](https://avatars.discourse-cdn.com/v4/letter/n/73ab20/32.png) [@ntabs](https://forum.bubble.io/u/ntabs)\ **Post date:** [January 20, 2023, 3:31pm UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/4 "2023-01-20T15:31:25Z")
Hi, I might be missing out on something but here’s my take > [@umiumansa](#): > > My issue really is with the view switch at the top, and the **initial load** of the RG. If the speed of filtering is not your issue, and it’s solely the slow initial load, I guess you would have to check your data structure? There are a lot of nuances when it comes to RG load speed, factors such as: Size of the data being loaded in to the RG, Initial search structure, filters, number and type of elements in the cells, not utilizing styles in the elements in the RG, and a bit more. I haven’t seen your DB structure but if you’re not utilizing satellite data types for your RGs, I would suggest you check it out. However, if you think your DB structure is already optimized, then I would have a look at the other factors that I have mentioned. Also, I highly suggest you use the daisy chain filtering method as what @rico.trevisan just showed. Been using it for quite some time and I’m in love with it 😍 Hope this helps! Best, Nino ---
**Author:** ![rico.trevisan](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/rico.trevisan/32/170176_2.png) [@rico.trevisan](https://forum.bubble.io/u/rico.trevisan)\ **Post date:** [January 20, 2023, 6:36pm UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/5 "2023-01-20T18:36:07Z")
To be clear, that video is from @Andrew.Vernon (I just fixed my original post with it). @umiumansa : I would suggest not pulling too much data into states. I once ran into problems with an application where I did that. With 10’s of items not an issue. The moment that started to grow past 100’s, the browser cache would fill up quickly and all sorts of weird things would happen; mobile browser crashed, laptops hung for a few seconds. And I think that when you put stuff in states it looses its direct connection with the database. I think that’s what I once read in one of @keith’s technical opuses. ---
**Author:** ![keith](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/keith/32/56020_2.png) [@keith](https://forum.bubble.io/u/keith)\ **Post date:** [January 20, 2023, 9:31pm UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/6 "2023-01-20T21:31:46Z")
I’m not following this thread closely, but I did look at @umiumansa’s video. When you see the “blue bar of death” like that it means that you are loading a large amount of data. That is, either you’re loading a s-ton of items or you’re not loading that many items, but the individual items have some heavy fields on them (e.g., as when one attaches a list of images directly on some datatype, which is generally a bad idea). In @umiumansa’s case, they are doing `Search for Tickets :filtered`. Unless there are some constraints inside that Search that they did not show in their screenshots, what this will do is download ALL TICKETS in the database to the browser. That’s the only way that` :filter` can work. If they want the initial load time to be shorter, they need to move some constraints into the initial Search so that the database doesn’t have to send every damn thing to the browser. Or only load the data that’s requested, _when_ it is actually requested. It’s that simple. As for your comment about custom states, @rico.trevisan, yes custom states only update when we Set them. If we set a custom state to be the results of a Search, the data held in the custom state is static rather than a live query to the database. So, if for example we stored `Search for all Tickets` in a custom state, if a new Ticket is created, the state will not magically update until we do it ourselves. (There’s an additional subtlety: Things are _also_ live queries [their primary fields will update if changed in the database]. So, if you’re storing a list of Things in a custom state and one of them gets deleted, the item at that Things position is still reflected in the list, but the Thing itself no longer exists and we would see its fields as all being empty. This is documented in the note at the bottom of [Using Custom States - Bubble Docs](https://manual.bubble.io/help-guides/structuring-an-application/custom-states#setting-a-custom-state). ) As for “pulling too much data into states”, of course browser memory is finite and there’s a lot of ways that we can crash the browser or blow up the call stack. In Bubble the most common way to do this is loading way more data than we have memory for (like what the OP is at risk of doing at scale). ---
**Author:** ![rico.trevisan](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/rico.trevisan/32/170176_2.png) [@rico.trevisan](https://forum.bubble.io/u/rico.trevisan)\ **Post date:** [January 20, 2023, 10:18pm UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/7 "2023-01-20T22:18:12Z")
Clear. Instructive. Epic. ❤Keith ---
**Author:** ![umiumansa](https://avatars.discourse-cdn.com/v4/letter/u/ccd318/32.png) [@umiumansa](https://forum.bubble.io/u/umiumansa)\ **Post date:** [January 23, 2023, 3:38am UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/8 "2023-01-23T03:38:45Z")
> [@ntabs](#): > > Size of the data being loaded in to the RG, Initial search structure, filters, number and type of elements in the cells, not utilizing styles in the elements in the RG, and a bit more. Hi and thanks. In the produciton version we have this issue too and we only have 109 tickets: ![image](https://us1.discourse-cdn.com/bubble/original/3X/8/5/857490917a78269c4313aa022ab7b9a4f1d29bfd.png) This surely isn’t “a lot of data”, right? As for the data structure: ![image](https://us1.discourse-cdn.com/bubble/original/3X/c/c/cc24f93909f5171abdcaa3af6962ddf8d7a86e50.png) The only thing I can imagine would take some time could be attachments which are currently a list of files and which I am planning to move to a related table. However, looking at the tickets, only a couple of them have attachments out of 109. All elements in the RG use styles. ---
**Author:** ![doug.burden](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/doug.burden/32/179967_2.png) [@doug.burden](https://forum.bubble.io/u/doug.burden)\ **Post date:** [January 23, 2023, 3:39am UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/9 "2023-01-23T03:39:40Z")
How big are them lists… Are these lists going to hold a handful of items or a plethora of items? Make them separate entries somewhere else. ---
**Author:** ![ntabs](https://avatars.discourse-cdn.com/v4/letter/n/73ab20/32.png) [@ntabs](https://forum.bubble.io/u/ntabs)\ **Post date:** [January 23, 2023, 3:55am UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/10 "2023-01-23T03:55:54Z")
Insane… 🙇‍♂️ At this point, @keith should very well publish a book about Bubble - pretty sure it’s gonna be funny as hell too! > [@keith](#): > > the data held in the custom state is static rather than a live query to the database Is there possibility that Bubble would add dynamic expressions to states? Recently ran into a roadblock that would’ve been very easy to solve if state values could be dynamically set ![image](https://us1.discourse-cdn.com/bubble/original/3X/2/f/2f6167f6e58387ea4b762569878219cb1d8ccaf4.png) What do you think, @keith? ---
**Author:** ![ntabs](https://avatars.discourse-cdn.com/v4/letter/n/73ab20/32.png) [@ntabs](https://forum.bubble.io/u/ntabs)\ **Post date:** [January 23, 2023, 3:59am UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/11 "2023-01-23T03:59:39Z")
Haven’t really dived too deep to your issue but maybe you should try utilizing satellite data types for your search instead? If current cell’s ticket is clicked, you could simply redirect them to a dedicated ticket page, popup, or group containing the current cell’s ticket parent data type Oh, and I suggest you apply what Keith said in his reply ---
**Author:** ![umiumansa](https://avatars.discourse-cdn.com/v4/letter/u/ccd318/32.png) [@umiumansa](https://forum.bubble.io/u/umiumansa)\ **Post date:** [January 23, 2023, 5:26am UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/12 "2023-01-23T05:26:18Z")
> [@ntabs](#): > > try utilizing satellite data types for your search instead Can you please clarify what _utilizing satellite data types_ means? ---
**Author:** ![keith](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/keith/32/56020_2.png) [@keith](https://forum.bubble.io/u/keith)\ **Post date:** [January 23, 2023, 5:46am UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/13 "2023-01-23T05:46:48Z")
Well if you want something that holds data like a custom state but that automatically updates when the value of the expression changes, you can use List Shifter or Floppy Expression Watcher (from my Floppy plugin) . Both of those take a list and / or scalar expression and publish the values to one or more outputs whenever the values change. They also throw an Initialized/Updated event so you know when that has happened. (This is all that Floppy Expression Watcher does. List Shifter has additional features for list transformation.) Edit: I suppose Groups also have this capability but they don’t actively generate an event when data changes, though you can watch for that using other techniques. I just find this easier with a dedicated plugin. ---
**Author:** ![umiumansa](https://avatars.discourse-cdn.com/v4/letter/u/ccd318/32.png) [@umiumansa](https://forum.bubble.io/u/umiumansa)\ **Post date:** [January 23, 2023, 5:55am UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/14 "2023-01-23T05:55:49Z")
Actually, I realize I was wrong in my assessment of the issue. After doing some troubleshooting, it appears to be the filtering that’s consuming time. Workflow 1 Refresh Ticket List will set a “Refresh” state in the filtering element and that in turn triggers a Workflow 2, Reset Filters: ![image](https://us1.discourse-cdn.com/bubble/original/3X/8/e/8eb086f7043e04123f2f5a5899587ad7e556cf1c.png) I set the Refresh value to NO and thus limiting the app to only refreshing the filter without refreshing the RG data and the issue persists. So it is not an issue with the RG but with the management of filters in states. By toggling some of the fitler values on and off, I see those that are time consiming are: - **Domains:** this one is searching for the list of ticket domains (topics) that belong to the current user’s team, by searching all the memberships of this user and getting the domain for each of these memberships. ![image](https://us1.discourse-cdn.com/bubble/original/3X/7/0/707167074bc2eb21e39bd647096a8d1d313ae050.png) - **Assignees:** this one is searching for the list of users that are in the team of the current user. This one will look for the users in the domains the current user is a member of. So it will look for all members ships where the domains are the domains of the current user: - **Requestor:** this one is searching for all requestors amon tickets. So looking back it may be down to the pulling of data into states as @rico.trevisan suggested and so the chain filtering may be the solution. I’ll do some tests to validate this hypothesis. ---
**Author:** ![ntabs](https://avatars.discourse-cdn.com/v4/letter/n/73ab20/32.png) [@ntabs](https://forum.bubble.io/u/ntabs)\ **Post date:** [January 23, 2023, 6:04am UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/15 "2023-01-23T06:04:46Z")
> **[Satellite Data Types In Bubble | Complete Guide](https://www.amliesolutions.com/bubble/advanced/satellite-data-types-in-bubble/)** > > Satellite Data Types help you structure your database in a way that makes your Bubble.io app run smoother. This article looks at some different scenarios. Check it out. @petter made a good guide about it ---
**Author:** ![umiumansa](https://avatars.discourse-cdn.com/v4/letter/u/ccd318/32.png) [@umiumansa](https://forum.bubble.io/u/umiumansa)\ **Post date:** [January 23, 2023, 6:08am UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/16 "2023-01-23T06:08:49Z")
OK I see it’s a lightweight version of actual data type we’re searching for. ---
**Author:** ![umiumansa](https://avatars.discourse-cdn.com/v4/letter/u/ccd318/32.png) [@umiumansa](https://forum.bubble.io/u/umiumansa)\ **Post date:** [January 23, 2023, 6:20am UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/17 "2023-01-23T06:20:07Z")
So after realizing my storage of search criteria in state is the cause of the slow down, I am looking again at your video. What I do not get from the video is where you store the search criteria. For example in my app I will store the selected statuses in a “statuses” state of the search and filtering group, whenever I save the desired filters select in this popup: ![image](https://us1.discourse-cdn.com/bubble/original/3X/a/2/a266e8cad50b7acfcf1280dcc9bdce66ff92160f.png) That would still be the case if I use chain filtering right? The custom event will need to look for the criteria so they need to be stored somewhere on the front end. When resetting the filters I would need to repopulate the custom state with all filters then too, right? When storing the status it’s not a big deal, as it’s a small finite set, but the issue is when filtering requestors, or assignees or domains for tickets as these are dynamic lists that contain more data. Somehow I would need to store the requestor users to include and exclude from the search. If I exclude one it means storing either storing one excluded or storing a lot of included, and the opposite for exlclude all except one. I suppose the default would be to include all, in which case the can use an empty state as the equivalent of including all and skipping the search by requestor when the state is empty. Take also the case of filtering by domains (which are topics of tickets). When switching to the Team View, I need: - The list of tickets related to domains to which the current user belongs. - The list of domains to which the current user belongs (to display as filter options in the filtering). - The list of domains to exclude (filtered out). The two lists of domains would need to be stored in state wouldn’t they? ---
**Author:** ![rico.trevisan](https://sea1.discourse-cdn.com/bubble/user_avatar/forum.bubble.io/rico.trevisan/32/170176_2.png) [@rico.trevisan](https://forum.bubble.io/u/rico.trevisan)\ **Post date:** [January 23, 2023, 7:56am UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/18 "2023-01-23T07:56:26Z")
The defaults are saved in each individual element. For instance, if you have a drop down for task status, it will revert to whatever you have set in the default of that element. * * * I appreciate how you been approaching the forum. Clear questions, lots of information, you try a proposed solution and revert back with your findings. High quality stuff. Here is a bearhug ticket 🎟, redeemable at any helpful forum regular near you. ---
**Author:** ![umiumansa](https://avatars.discourse-cdn.com/v4/letter/u/ccd318/32.png) [@umiumansa](https://forum.bubble.io/u/umiumansa)\ **Post date:** [January 24, 2023, 4:21am UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/19 "2023-01-24T04:21:32Z")
Hi, So I’ve completed the changes and it’s a lot smoother now! Thanks. Here are things learned, in case it serves in the future: 1. I made the mistake of storing too much on states, though some filtering is required in states, it is slowing down performance. To be more precise, I made the mistake of storing the “included” values, rather than “excluded” values. So the best is to assumed the user wants all data (i.e. blank state storage) and add to the state the values that need to be excluded from the filtering. 2. The chain filtering seems to help indeed. It’s counter-intuitive, as it seems to make a lot of unecessary calls, but it is efficient. The part that surely helps I asusme, is that we filter the group’s own data and feed it back to the group, which makes the dataset ever narrower. 3. Although I have not done so at the moment, using proxy data types for the search (or sattelites as called above) may make the app more efficient searching and loading the dataset. ---
**Author:** ![system](https://us1.discourse-cdn.com/bubble/original/3X/2/8/2847faa74692c2ffa5d939d3dc3724cdd060d247.png) [@system](https://forum.bubble.io/u/system)\ **Post date:** [March 31, 2023, 2:17pm UTC](https://forum.bubble.io/t/slow-performance-with-repeating-group-filtering/242513/20 "2023-03-31T14:17:43Z")
Closed on March 31, 2023, 2:17pm UTC This topic was automatically closed after 70 days. New replies are no longer allowed.