Уничтожение древовидных структурных векторов std :: unique_ptr

Я перенес свой код для использования std :: unique_ptr.

Когда мне нужно было выбрать один класс с древовидной иерархией, я решил предоставить объекту свои дочерние объекты, чтобы удалить объект из дерева.
Однако я заметил, что в сложных иерархиях тысяч элементов уничтожение происходит очень медленно. Мол, невероятно медленно.

Так что просто советуют не вкладывать векторы уникальных указателей, и я должен переключиться на плоскую разметку unique_ptr, и просто сохранять регулярные указатели в дереве?
Я представляю, что это может быть общеизвестным фактом, что это не пойдет, но это озадачивает меня, так как мне было трудно найти литературу по этой конкретной детали.

#include <vector>
#include <memory>

class Element
{
std::vector<std::unique_ptr<Element>> mChildren;
};

ОБНОВЛЕНИЕ: После долгих колебаний, чтобы удалить мой вопрос, я заметил, что моя проблема очень похожа на эту:
быстрый способ удалить записи вектора STL из указателей

С добавлением, что процесс еще медленнее с древовидной структурой. unique_ptr кажется, не несет ответственности здесь в конце концов.

Я написал кусок кода, чтобы исследовать его

  • уничтожить 60 000 элементов, unique_ptr, плоская планировка занимает около 5 секунд

  • уничтожить 60 000 элементов, unique_ptrмакет дерева занимает около 8 секунд

Без unique_ptr время только незначительно ниже.

Таким образом, настоящая проблема, с которой я сталкиваюсь, заключается в том, что медленно удаляется 60 000 вещей подряд.
Тогда я представляю, что мои решения похожи на те, что в связанном вопросе:

  • Память пула для элементов, которые, как я знаю, я собираюсь удалить пакетами, но говорят, что это очень громоздко и может привести к серьезным ошибкам

  • Сделайте это с рабочим потоком, то есть он будет работать медленно, но больше не будет мешать основному потоку.

Я технически неуверен в том, как правильно выполнить оба, но я полагаю, что это научит меня.

0

Решение

Задача ещё не решена.

Другие решения


По вопросам рекламы [email protected]