Premium support for our pure JavaScript UI components


Post by pincherhgz »

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


Post by mats »

Can you reproduce this in our online samples?


Post by pincherhgz »

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
Attachments
record-1.png
record-1.png (113 KiB) Viewed 344 times
record-2.png
record-2.png (100.6 KiB) Viewed 344 times

Post by alex.l »

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?

All the best,
Alex


Post by pincherhgz »

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

Attachments
dependencies.json.zip
(342.91 KiB) Downloaded 14 times
testData.json.zip
(1.04 MiB) Downloaded 14 times

Post by alex.l »

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
},

All the best,
Alex


Post by pincherhgz »

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


Post by alex.l »

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.

All the best,
Alex


Post by pincherhgz »

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

Last edited by pincherhgz on Fri Feb 03, 2023 3:56 pm, edited 1 time in total.

Post by alex.l »

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

All the best,
Alex


Post Reply