Community
Participate
Working Groups
If I synchronize a JIRA query (with 9 tasks) the heap allocation will jump up and down. It will start at 80 MB, go up to 160 MB which triggers a garbage collection slowing down Eclipse significantly. This will happen for _each_ task that is synchronized. The memory analysis shows that 93% of the garbage collected objects were allocated in org.eclipse.mylyn.tasks.core.AbstractTaskContainer.getChildren() totaling almost 900,000 objects.
Forget me if I'd state the obvious, but it does make sense in getChildren() check if there is no children and return Collections.EMPTY_SET and also maybe initialize children field lazily. The latter was one of the objections for patch on bug 199818
Great catch Steffen.
A more detailed analysis showed that the memory is allocated by Axis so there is not much we can do about it. The reason it was affecting performance badly was bug 207652 which caused every task to get synchronized through SOAP on each background synchronization. With that bug fixed the JIRA connector will not make SOAP calls during background synchronization and it should be noted that we need to look out for that when changing the synchronization logic. This performance problem still exists when manually synchronizing queries or tasks. It might be worth investigating a switch to Axis2 which is supposed to have better performance and consume less memory.
Steffen, very interesting. Though I think it is still worth to fix stuff I mentioned in comment #1.
Thanks for pointing that out. I have opened bug 207659.
