Community
Participate
Working Groups
It would be nice if some class hierarchy information could be cached in an EvaluationContext, when evaluating an AdaptExpression. A common case is to have a common evaluation context which will be used to evaluate several (i.e., perhaps hundreds) of expressions. It would be nice if it were possible to cache some of the hierarchy information, rather than recomputing it each time.
Hi Douglas, I see your point the only problem is that the adpat is not statically and might therefore not be cachable. For example: IAdaptable a= ....; IResource r= (IResource)a.getAdapter(IResource.class); assert(r == null); .... IResource r= (IResource)a.getAdapter(IResource.class); assert(r != null); could be completely legal code since whether or not a object is adaptable could depend on some state of that object or even on some state of the adpater factory. So this can only be optional where the evaluator knows about the adapt behaviour of the variables.
I realize now the the Summary was a bit misleading. I was thinking more of caching the superclass/interface/superinterface look-ups. My thought was also to use the EvaluationContext itself to cache the information. This gives some control to the application as to when this information is flushed.
Hmm, may be I am not understanding it but the adapt expression is using core API to actually do the adaption. IAdapterManager manager= Platform.getAdapterManager(); if (!manager.hasAdapter(var, fTypeName)) return EvaluationResult.FALSE; adapted= manager.getAdapter(var, fTypeName); I don't see how we can cache anything there (I even think core is already doing some caching here).
It's possible I'm misunderstanding. My concern is more with this line: Expressions.isInstanceOf(var, fTypeName) Jean-Michel would understand more, as he wrote the caching mechanism used in ObjectContributorManager.
OK, now I understand. Michael, is there some API code I can resue ?
Now although this was a while ago, let me see if I can remember any of the details. Most of the performance problems I found trying to add support for true adaptable contributors related to hierarchy checks based on type name. There were others, like finding the common types for a selection considering adapters. I thought of adding the type lookup cache in AdapterManager, because that is a good common class which performs the lookup already. Another performance issue, or plug-in loading, is how often the selection is adapted to the target type for each action. For example, if 5 actions take IFoo types, then how many type does the contribution code traverse the selection and adapt it? I propose that you profile the new code before jumping to conclusions though.
Moving bugs due to ownership change.
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.
