Bug 152389 - Performance of edit part's refreshXxx() could be optimized
Summary: Performance of edit part's refreshXxx() could be optimized
Status: RESOLVED FIXED
Alias: None
Product: GEF
Classification: Tools
Component: GEF-Legacy GEF (MVC) (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: gef-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance, plan
Depends on: 162316
Blocks:
  Show dependency tree
 
Reported: 2006-07-31 18:50 EDT by Yasser Lulu CLA
Modified: 2010-11-13 06:50 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yasser Lulu CLA 2006-07-31 18:50:17 EDT
The following functions: 
AbstractEditPart::refreshChildren(),
AbstractGraphicalEditPart::refreshSourceConnections()
AbstractGraphicalEditPart::refreshTargetConnections()

could check for the lists they try to manipulate if they are empty or not and exit immediately without incurring the unnecessary overhead of executing their method bodies
Comment 1 Anthony Hunter CLA 2006-12-11 15:11:59 EST
This is an issue raised during performance testing.
Comment 2 Randy Hudson CLA 2006-12-11 16:27:12 EST
FYI - Raj (don't make me spell his whole name) has already submitted this bug and the patch to address the problem.

OT - clients should not be calling the refreshX() methods for simple model changes. Instead, addChild(...), removeChild(...) etc. should be called directly.
Comment 3 Alexander Nyßen CLA 2010-11-06 05:43:05 EDT
Added a dependency to bug 162316, reported by Raj, which is not a full duplicate but addresses the refreshSourceConnections() and refreshTargetConnections() performance and memory issues.
Comment 4 Alexander Nyßen CLA 2010-11-13 06:50:15 EST
With the changes performed in bug #162316 (while this bug targeted the memory consumption of the respective methods), I think most that is achievable has been done. I am thus closing this one as being fixed as well. If you have any concrete points where you think the current implementation (cvs HEAD) will have to be additionally tuned, please reopen and comment.