• S sverchok
  • Информация о проекте
    • Информация о проекте
    • Активность
    • Метки
    • Участники
  • Репозиторий
    • Репозиторий
    • Файлы
    • Коммиты
    • Ветки
    • Теги
    • Участники
    • Диаграмма
    • Сравнение
  • Задачи 148
    • Задачи 148
    • Список
    • Доски
    • Спринты
  • Запросы на слияние 21
    • Запросы на слияние 21
  • CI/CD
    • CI/CD
    • Конвейеры
    • Задания
    • Расписания
  • Развертывания
    • Развертывания
    • Окружения
    • Релизы
  • Пакеты и реестры
    • Пакеты и реестры
    • Реестр пакетов
    • Реестр контейнеров
  • Мониторинг
    • Мониторинг
    • Инциденты
  • Аналитика
    • Аналитика
    • Поток ценности
    • CI/CD
    • Репозиторий
  • Wiki
    • Wiki
  • Сниппеты
    • Сниппеты
  • Активность
  • Диаграмма
  • Создать новую задачу
  • Задания
  • Коммиты
  • Доски с задачами
Свернуть панель
  • nikitronn
  • sverchok
  • Задачи
  • #4227
Закр.
Открыто
Задача созд. Июл 14, 2021 пользователемnikitronn@nikitronnВладелец

Sv_get bottleneck

Created by: Durman

Problem statement

Before starting process a node is reading data from previous node and other node, thanks to Blender data structure, can be get only via search. So in big trees and in trees with loop nodes this search takes significant time. I have two benchmark examples. First example has loops and the search takes 50% of all execution time. The second example does not have loop nodes but it's big. The search takes 10% of time there.

with loop nodes

output

just big tree (400 nodes)

output (1)

The solution is to make them not to search the previous nodes.

  • First what come to mind is to use udpate system for the search. Update system has its own more efficient representation of a tree. But the thing is that it is not always has updated state. It's reliable only during update event. But nodes also can use search before update event (for example to find what is socket type of previous node)
  • Another solution is to make update system to copy link to output of nodes to input of next nodes. The storage of data of input sockets can have similar implementation as it's now for output sockets.

Also there is another problem which probably should be fixed together. Output sockets inside node groups can have multiple outputs and current storage system of sockets data does not support multiple values. To solve the problem I made a trick in node groups. When a node group is evaluated all node IDs are changed and it helps to storage system to put values in appropriate place for current group. But it's really nasty thing to do. The node ids should be always constant.

Ответственный
Назначить
Оценка трудозатрат