Community
Participate
Working Groups
There are several performance issues when sharing large projects (~20000 resources). 1) In this case, there are a large number of unmanaged, unignored resources. The isIgnored check is expensive in this case as all parents must be checked. This is compounded by the need to check for each resource. This may happen several times during a share. The easiest solution may be to cache the fact that an unmanaged folder is not ignored in the session properties. 2) When the ResourceVariantTree collects changes, it traverses all resources of the project even though none have any remote state. It should only need to traverse those resouces that are locally managed or have remote state. This is probably not to complicated but will require API. 3) At some point, the sharing wizard needs to wait for the SubscriberEventHandler to populate the sync page. During this time, there is no progress feedback (and ignore checking is occuring so it is slow). 4) Clicking Finish will bring up the Commit Dialog which repopulates another sync page. Progress is better but the user ends up waiting twice for the same thing. 5) After clicking Finish in the Commit dialog, all the resources are added and then committed. These are large operations and are more susceptible to failure. It is common for the Commit to time out, for instance.
I had to remove a subTask call from the AbstractResourceVariantTree#collectChanges method since it was slowing down the sync considerably on GTK (see bug 97818). This could be re-added once point 2 is addressed.
Point 2 also has an impact on committing. If there is a large ignored directory, then committing from the navigatpr takes a long time to collect all the changes.
There is currently no plan to address this issue.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
