Running into major performance issue with appending to list of things repeatedly

Hello,

I have been running into a major performance issue when attempting to append things to an existing list of things in state. The general premise is as follows (given in the context of an example for simplicity):

Premise

A user wants to create a new Collection. A Collection has a field, which is a list of Items, another thing. Each Item has a name and a cost. In this case, assume a user has the desire to be able to specify Items in the collection while creating it, rather than having to create the Collection and add Items later. Furthermore, if they change their mind mid-creation, the Collection shouldn’t be created.

The user goes to a page to create a new Collection. On that page they can specify a Collection name, as well as an indeterminate number of Items that go in the collection. For each Item the user wants to add, they input an Item name and an Item cost. They then click an “Add” button, which will cause the Item to show in a repeating group of previously added Items. Finally, when they are done adding items, they click the “Create Collection” button, which creates the Collection and adds the items to it.

Technical Details

In our example, the repeating group showing the added products (repeatingroup staged products) has a custom state (Staged Products) which is a list of type Item. The datasource of repeatinggroup staged products is its Staged Products State.

The workflows are as follows:

“Add” button:

  1. Create thing (type: Item) (fields: name = input item name’s value, cost = input item cost’s value)
  2. Set state (element: repeatinggroup staged items) (state: Staged Items) (value = repeatinggroup staged items’ Staged Items:plus item result of step 1)
  3. Reset relevant inputs

“Create Collection” button:

  1. Create thing (type: Collection) (fields: name = input collection name’s value, items = repeatingroup staged items’ Staged Items)
  2. Set state (element: repeatinggroup staged items) (state: Staged Items) ( value = )
  3. Reset relevant inputs
  4. Go to page collection_view (data: result of step 1)

The Problem

The problem is this: When a user adds the first Item, there is practically no delay. The same goes for the second item. On adding the third item, there is a noticable delay of a couple seconds. The fourth item takes around 10 seconds to be added. The fifth item takes over 20 seconds to be added. I haven’t tested past 5 items, but I assume that the delay gets exponentially worse as time goes on.

I understand that performance will lag as lists get larger, especially since I assume :plus_item requires making a copy of the list. However, the performance hit should not reasonably be this noticeable, especially after only a few items being added to the list.

Don’t know if it will help, but at first blush, I’m wondering if the state is actually needed. Have you tried setting the Staged Items data source to “Do a search for [items from the DB]”?

IOW, create a “draft” collection in the DB. Then, when the user clicks the “Create Collection” button, it really just changes the collection from “draft” to “published”.

So the reason I designed it this way is because I’d much prefer staged Items to not be in the database at all until the Collection is created, but bubble doesn’t allow you to create things exclusively in state. So as a sort of compromise, I hold references to them in state so that if the user cancels they can be deleted. As you suggested, it would be possible to have a “draft collection” item for each user and have it have a list of staged products, but that would require even more unnecessary database read and writes.

You can read more on my frustration on the lack of local storage support in bubble at the following forum post, but I’ll try to keep the focus of this thread on the bug report at hand.

EDIT: Link

But if you haven’t already tried it, it might be worth a try to see if there’s a performance gain, which seems to be the main concern.

Bubble’s auto-bind feature keeps data in sync with the view without having to explicitly “save”. I mention that only to suggest that DB reads/writes aren’t usually a big deal unless you’re pulling a huge list or something.

Fair enough, I’ll give it a shot and see if it helps, thanks. Regardless, I’ll leave this open because either way state lists probably shouldn’t have this issue.

An update:

I’ve implemented a version of the suggestion above, such that instead of storing Items in state, Items are stored in a field of a separate type called a “Collection Draft” which is attached to the current user. Interestingly enough, there was little to no performance improvement while making this change, despite not using state anymore. This to me suggests that it has to do with how repeated adds to a list are handled in general rather than states, so I am updating the title accordingly.

Other Findings

What DOES seem to affect it are performing other actions. For instance, if you remove an Item from the list, and then go to add new Items, the performance drastically improves, before creeping up to the 10s of seconds as you add several more items. Refreshing the page sometimes seems to have similar results as well.

A couple potential ideas come to mind as to what could be causing this behavior. There could be an issue with how lists are optimized internally, such that in certain list lengths and orders, adding runs into a slowdown. Alternatively, it’s possible that bubble is artificially (either on intention or by accident) introducing slowdowns in repeated calls to the same workflow in a row, as is the case here. This could be intended to prevent spam measures, but ends up hurting the user experience.

Interesting. It definitely shouldn’t take tens of seconds for what you describe to occur. If you suspect a legitimate performance issue, you can submit a bug report.

If you can demonstrate the issue in a simplified example outside your app and provide view access to the editor, other community members might be able to make further suggestions. Plus, it will come in handy if you decide to submit a bug report.

After attempting to reproduce the issue to no avail in a test app, I finally discovered what seems to be causing the issue. On my existing app, there is an option labelled “Enable Responsive Page Rendering Engine”. This option doesn’t exist on my test app, but seems to just be enabled by default. Checking this box exposes two new options, “Make this element fixed-width” and “Minimum width (% of current width)”.

Enabling this option causes the performance issues to essentially disappear. I’m unsure why the option isn’t available on my test app but is on my existing app, but at least enabling it fixed the issue. Unfortunately, doing so messes with the formatting of the existing page, but at least I can go and fix that.

This topic was automatically closed after 14 days. New replies are no longer allowed.