Community
Participate
Working Groups
Two areas of possible optimization: ComponentGraphicalEditPart.contributeModelSize(...) This method calls getBounds() on the target VM which calls getSize() and getLocation() inside ComponentManager. Instead it can juste call getSize() and also ComponentManager.getBounds() can be optimized to do a single method call to the target Also ComponentManager.fireComponentRefresh() on initial open causes a re-query of the bounds from the target VM. I don't believe this is necessary on open (although it might be later in which case we need to defer its activation). Quick fixes to ComponentGraphicalEditPart and ComponentManager yeield a possible performance improvement of 92% of previous open time as below. This bugzilla is to track the progress of this item. ice warm warm warm warm before 18997 5638 6294 6029 5418 getSize patch 18186 5888 5318 5678 5238 getSize path 18042 5938 5077 5057 5087 0.953518977 1.048776162 0.825786463 0.890280312 0.952842377 0.934240858 getSize + no fire refresh 17965 5689 5118 5957 4737 0.945675633 1.009045761 0.813155386 0.988057721 0.874307863 0.926048473
Rich, I'd like to get your input as to when ComponentManager.fireComponentRefresh() is required. Commenting it out during first open doesn't seem to break anything, so can we optimize its usage to prevent unnecessary target VM traffic ?
It's needed later on when we have things already up and running and add things, plus I think it is needed on reload from scratch. First time open is always a very special sequence that is different then normal operations. It is necessary to get the bounds too since until that occurs we don't necessarily get the correct bounds. It changes from (0x0) to the actual sometime between creation and this period. Without it we may miss the true bounds. This may not be seen on anything with a layout manager because until the layout occurs it is not sized, but this can happen with null layout.
