Adding items to large sets from the set view breaks the app

Describe the bug

When viewing large sets, using the + button to add a new row to the table gets slower and slower the larger the set is, and after a certain point, starts breaking the entire app. My largest set is currently 796 items. Creating a new object of this type (through any mechanism, but it’s worst from the set/table view) is very slow, with about a twenty-second lag between clicking the button and seeing the response. Attempting to create more than 5-10 rows during one session (even if they’re 5 minutes apart), or creating more than 3 rows with a series of clicks, results in the following problem.

A new object is created, but is never displayed. If you return to the home screen, you’ll find that none of the links to pages or sets will respond to clicks anymore. Sometimes, searching results in a blank, infinitely-loading result list. Other times, you’ll still get a result list, but trying to load a page from it gets you the infinitely-loading white screen. The only solution seems to be to relaunch Anytype entirely.

This sort of amounts to a de facto limit on the number of objects in a set/of a given type, because it becomes too slow and too unstable to add more.

To Reproduce

Steps to reproduce the behavior:

    1. Create a set with a large number of items.
    1. Attempt to add multiple new items through the + button in the Set view, especially by clicking the button 5 or 6 times in a row.
    1. Attempt then to access other pages, through search or the home screen.

Desktop (please complete the following information):

  • OS: Windows 11 (build 22000.168)
  • Device: Ryzen 5 3500U with 24 GB RAM
  • Version: 0.18.68

Additional context

AnyType’s memory usage doesn’t seem to spike when loading or browsing the large set, and the issue occurs even when AnyType is the only program running on a freshly-booted system, consuming only 1.1 GB of the 24 GB available RAM. That was the first thing I checked.

The objects in the 796-item set are a custom type with 4 tag relations, a date relation, a numeric relation, and a checkbox relation.

I do have a relation-related error when I run AnyType from the terminal with ANYTYPE_LOG_LEVEL=*=DEBUG, but I’m not sure if it’s related, I was going to ask about it in a separate post/email about a different issue:

{ ... "logger":"anytype-mw-source", "caller":"source/source.go:213", "msg":"not valid state: failed to validate relations: relation for detail 611c33a6952e1241e8a9088a not found", "thread":"bafyba7etqonhf7hrbhmkune6n5smbjzmftqouowx6vibfwm6h323qy75", "sbType":16 }

1 Like

@triangles Thank you for your notice! It has been added to the bug tracker

1 Like

I might be wrong about the cause. Others have mentioned using large sets without slowdown, so I experimented, and the problem seems to be with tag relations. I created a brand-new type, zero existing objects. Creating a new object from it took under a second. [Here’s a little video](Dropbox - anytype_slow_objects.mp4 - Simplify your life) showing how it gets slower and slower as I add tag relations to it. Even getting the menu to define the fourth tag relation takes a while, and brings the new-object creation time up to 15 seconds. I have around 200 tags in the suggestion list/“Filter or create options” box, if that’s relevant.

1 Like