Change Details

Outliner remapping is slow. Reason is that per ID remap it needs to go over the whole treestore. Outliner has a reverse lookup, but isn't usable for cases where you only have a part of its key. space_outliner->runtime->treehash can contain a GHash. The key of the treehash is an encoding of: * TreeStoreElem.type * TreeStoreElem.nr * TreeStoreElem.id Due to its encoding it is only possible to do a reverse lookup when all 3 elements are known. nr seems to be the index of a modifier it points to. Type is very divers and seems to implement multiple indexing in a single ghash. # Alternative 1: remapping user data Use a custom reverse lookup for remapping. Current codebase would only benefit of having a reverse lookup during remapping. Adding a user data to the remapping process needs many changes in the ID management control flow. Current control flow ``` For each ID: for each screen: for each area: for each space: perform remap ``` In this situation the remapping should be stored on the highest level and requires a lookup to the user data along the way. This lookup can be eliminated by adding a remap process init and free function or by lazy initialization with a free function. # Alternative 2: Bulk test A hacky alternative is to use the space_outliner->runtime->treehash and loop over all possible `TreeStoreElem.type`. This leads to unmaintainable code and many lookups that doesn't count. The number of searches could be reduced by keeping track of each used TreeStoreElem.type per IDType. This data still needs to be stored in the space data and would still require a free function as we don't want to keep this data around. # Alternative 3: Remap multiple. Create arrays containing all the remappings that needs to be done. In stead of doing them one by one do perform them for the whole array at once. This would need a large refactoring of existing code (delete, loading, resync etc) with a lot of unknows. To mitigate the complexity we could support both (single remap and multiple remap. And migrate per functionality, but that has the possibility that the current implementation will never be phased out.

Outliner remapping is slow. Reason is that per ID remap it needs to go over the whole treestore. Outliner has a reverse lookup, but isn't usable for cases where you only have a part of its key. space_outliner->runtime->treehash can contain a GHash. The key of the treehash is an encoding of: * TreeStoreElem.type * TreeStoreElem.nr * TreeStoreElem.id Due to its encoding it is only possible to do a reverse lookup when all 3 elements are known. nr seems to be the index of a modifier it points to. Type is very divers and seems to implement multiple indexing in a single ghash. # Alternative 1: remapping user data Use a custom reverse lookup for remapping. Current codebase would only benefit of having a reverse lookup during remapping. Adding a user data to the remapping process needs many changes in the ID management control flow. Current control flow ``` For each ID: for each screen: for each area: for each space: perform space remap ``` In this situation the remapping should be stored on the highest level and requires a lookup to the user data along the way. This lookup can be eliminated by adding a remap process init and free function or by lazy initialization with a free function. # Alternative 2: Bulk test A hacky alternative is to use the space_outliner->runtime->treehash and loop over all possible `TreeStoreElem.type`. This leads to unmaintainable code and many lookups that doesn't count. The number of searches could be reduced by keeping track of each used TreeStoreElem.type per IDType. This data still needs to be stored in the space data and would still require a free function as we don't want to keep this data around. # Alternative 3: Remap multiple. Create arrays containing all the remappings that needs to be done. In stead of doing them one by one do perform them for the whole array at once. This would need a large refactoring of existing code (delete, loading, resync etc) with a lot of unknows. To mitigate the complexity we could support both (single remap and multiple remap. And migrate per functionality, but that has the possibility that the current implementation will never be phased out.

Outliner remapping is slow. Reason is that per ID remap it needs to go over the whole treestore. Outliner has a reverse lookup, but isn't usable for cases where you only have a part of its key. space_outliner->runtime->treehash can contain a GHash. The key of the treehash is an encoding of: * TreeStoreElem.type * TreeStoreElem.nr * TreeStoreElem.id Due to its encoding it is only possible to do a reverse lookup when all 3 elements are known. nr seems to be the index of a modifier it points to. Type is very divers and seems to implement multiple indexing in a single ghash. # Alternative 1: remapping user data Use a custom reverse lookup for remapping. Current codebase would only benefit of having a reverse lookup during remapping. Adding a user data to the remapping process needs many changes in the ID management control flow. Current control flow ``` For each ID: for each screen: for each area: for each space: perform space remap ``` In this situation the remapping should be stored on the highest level and requires a lookup to the user data along the way. This lookup can be eliminated by adding a remap process init and free function or by lazy initialization with a free function. # Alternative 2: Bulk test A hacky alternative is to use the space_outliner->runtime->treehash and loop over all possible `TreeStoreElem.type`. This leads to unmaintainable code and many lookups that doesn't count. The number of searches could be reduced by keeping track of each used TreeStoreElem.type per IDType. This data still needs to be stored in the space data and would still require a free function as we don't want to keep this data around. # Alternative 3: Remap multiple. Create arrays containing all the remappings that needs to be done. In stead of doing them one by one do perform them for the whole array at once. This would need a large refactoring of existing code (delete, loading, resync etc) with a lot of unknows. To mitigate the complexity we could support both (single remap and multiple remap. And migrate per functionality, but that has the possibility that the current implementation will never be phased out.