Bryntum Support Forums

we do have around 20000 tasks with around 20 root tasks (the others somehow children). When we delete on root object having not any children via applyChangeset, changes.removed it takes even on brand new M1 MacBook around 40 seconds until the gantt is usable (no sorters applied ...).

The same if we do an interactive delete with your standard delete context option

Can you reproduce this in our online samples?

unfortunately your big data set demo does not show this kind of behavior. Could it be influenced by the amount of data we have in one record, current data are like see attachments.

Measures:

• initially store data to store (around 20000 tasks), around 3 seconds
• delete one single task, around 30 seconds

Could you please attach data JSON we could use to reproduce the issue, together with instructions what exactly should be done to have this lag?
As I understood, you didn't remove a task with context menu, but apply changeset that removes some task with 99 subtasks?

Hi, the long time occurs on deleting/adding (even a task without any sub structure) via UI or via applyChanges. So if you use the attached test data you could just try to delete one of the (PR) objects on top level without a sub structure
added also the dependencies

Could you please share your TaskModel too, I see you used different field names for task model. So, I need to know if you used mapping for startDate -> scheduledStartDate, and so on for endData. I see it equals to "-1" which is not correct date.

    {
      "uUid": "939fbb44-6a2e-4bb5-9884-4a19a60dfe07",
      "nodePath": "/(PR)989898",
      "state": 0,
      "classIdentifier": "(PR)",
      "icon": "icons/%28PR%29.svg",
      "linkUuid": "939fbb44-6a2e-4bb5-9884-4a19a60dfe07",
      "childNodes": [

  ],
  "objectName": "989898",
  "select": false,
  "active": true,
  "description": "",
  "localViewURL": "",
  "feedbackState": 0,
  "feedbackStateDetails": {
    "own": {
      "number": 0,
      "ended": 0,
      "started": 0,
      "error": 0
    },
    "logicalIdentities": {
      "number": 0,
      "ended": 0,
      "started": 0,
      "error": 0
    }
  },
  "scheduledStartDate": -1,
  "scheduledEndDate": -1,
  "scheduledState": 0,
  "name": "989898",
  "id": "939fbb44-6a2e-4bb5-9884-4a19a60dfe07",
  "inactive": true
},

we set the the Bryntum startDate and endDate in case the object is scheduled. The non Bryntum attributes are just for us internally

Ok, I was able to reproduce performance problem with your data. I've opened a ticket to investigate that: https://github.com/bryntum/support/issues/6099

Thanks for providing test data.

by the way the same situation is with adding an object. Just as an info (I'm sure that you are anyway working on that with high priority), this problem currently delays our system rollout at one of our biggest customers

Thanks for the info. We will check all scenarios in the ticket above. I will add a note.