| Re: [mdt-papyrus.dev] [Performance] Css/stereotypes element creation |
|
Hi Christian, Thanks for your answer, I made some comment inline. I merged small patches this morning that will improve the performance I will try to improve the perf without changing the css engine. Regards, Benoit De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Christian Damus Hi, Benoit, See some replies in-line, below. HTH, Christian On 27 July, 2016 at 09:47:31, MAGGI Benoit (benoit.maggi@xxxxxx) wrote:
They are cached in the CacheAdapter. If they appear not to be cached, it is because some changes are being made in the resource set that cause the cache to be cleared. But the Element::getValue(…)
operation is not cached (I doubt that it would help if it were). In UML2 5.3, I contributed an API that provides for caching within the UMLUtil methods that look up profile definitions. It significantly improves the performance of all of these stereotype-related
APIs for statically-generated profiles (dynamic profiles don’t have nearly such performance problem). But, this API will only be available in the UML2 Oxygen release, so you wouldn’t have it for Neon.1. Have a look at http://eclip.se/497359 for
details. I will look at it. Is there a gerrit for the patch?
What does this mean? Currently the notification has only elementAdapter in parameter, I believe that the GMF notification will be required to make a fine refresh. Did I missed something? public
void notifyChange(Element
elementAdapter) {
I don’t understand. Opening a diagram is not a modification of anything. It doesn’t change the notation model. What is this ADD event? My bad, it’s when opening a model. I got notification in the SyleListener
Perhaps the DiagramHelper could be installed in the editor as an IService? But as of Neon release, it isn’t an object; it’s a suite of static utilities. Changing that would be an API-breaking
change. Although, perhaps most of the existing static API could remain as a façade in front of the new service instance, because all of the non-deprecated methods accept a parameter from which the Service Registry could be inferred (the parameterless forceRefresh
and scheduleRefresh methods should be deprecated, too, IMHO; I don't know why they aren’t) With a service, maybe your DSML could have a higher-priority service-factory that installs your helper for editors on SysML models but delegates to the default factory otherwise? It becomes
difficult when more than one DSML wants to be able to do this; we would need to define a new kind of service-factory that implements the Chain of Responsibility pattern. Maybe the DiagramHelperService would just be a service that provides the diagram-helper
and lets its clients replace the helper implementation if they need to. (that’s enough thinking out loud for me for one day) Too complicated/risky for a neon integration
|
