Details
-
Type:
Sub-task
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.0
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
Currently the MetaClass mechanism has no clean way for a descendent metaclass or runtime code to know if a property or method exists - including those dynamically intercepted/provided by the metaclass.
This means you have to rely on exceptions and this is very costly in performance terms in a multi threaded environment.
See http://jira.codehaus.org/browse/GRAILS-1036
This is a Grails issue with code attached for a workaround for the lack of a hasProperty, hasMethod and hasClosure method on MetaClass. It is ugly but it works, by caching the result of invocations / pickMethod and encoding some special behaviour related to closures. This duplicates/mutates logic currently in MetaClassImpl.invokeMethod() which is a bad thing.
We have seen a 30-50% speed increase in serving Grails pages in concurrent tests after using this new metaclass, instead of catching MissingMethodException and MissingPropertyException.
Also I believe that MetaClass should have invokeClosure on it, and remove some of the closure calling logic from invokeMethod, as this makes for a cleaner separation.
Issue Links
- depends upon
-
GROOVY-2503
MOP 2.0 design inflluencing issues
-