Re: [jboss-dev-forums] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection

Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion "JBoss Reflect Performance Javassist vs Introspection" To view the discussion, visit: http://community.jboss.org/message/543921#543921 -------------------------------------------------------------- Although too early to say yet, it looks like the classpools are a bottleneck. I have started caching things a bit more and that is speeding things up somewhat. For example calling CtBehavior.getParameterTypes() is slow since it does not cache the parameter types, instead for every call to this it parses the method signature and then hits the classpools for every class. I am attempting to avoid that as much as possible. Another observation is that quite a few calls to JavassistMethodInfo.getParameterTypes() are only interested in the length of the parameters and the names of the parameter types, so it might be an idea to return an array of "lazy" type infos which only know the name and the declaring typeinfo. I can be found out easily from the raw method signature (I am already passing the SignatureKey into JavassistMethodInfo and using that in its equals() method to avoid having to load parameters there). Once something more advanced is called, then that could obtain the real typeinfo and delegate to that. I'm not 100% sure yet if this is what I want to do. Once I am done with caching things as much as possible, we'll see if the classpools are still a bottleneck since there will be a lot less calls. If they are, I have an idea for how to change them into something simpler, but just want to jot it down so Flavia can take a look and see if she thinks it is a good idea or if I have missed something. The idea is quite simple, rather than managing the domains and pools and essentially recreating what the classloaders do, it might make sense to delegate everything to the classloaders. If we had a method like this, as I discussed with Ales (let's say it goes in the ClassLoading class, although where is up to Ales): ClassLoader getClassLoaderForClass(ClassLoader initiating, String classname); And we have a map of classpools by classloader in the classpool registry. Then I think our "dumb" class pool would not need much more than this - it has a null parent class DumbClassPool extends ClassPool{       WeakReference<ClassLoader> cl;     ClassPoolRepository repo;       DumbClassPool(ClassLoader cl, ClassPoolRepository repo){       this.cl = new WeakReference<ClassLoader>(cl);       this.repo = repo;     }         CtClass get(String classname){         //Check cache first, if not found then do the rest           CtClass clazz = super.get0(classname);         if (clazz != null)            return clazz;           String real = adjustForArraysAndPrimitives(classname);         ClassLoader loader = ClassLoading.getClassLoaderForClass(cl.get(), real);           ClassPool pool = repo.registerClassLoader(loader);         if (pool != null)         {            clazz = pool.getOrNull(classname); //new method from Chiba that does not throw NFE, but behaves like get()         }           if (clazz != null)            //cache class         else            throw new NotFoundException     } } I'd obviously be extending ScopedClassPool or whatever is needed in AOP and other places. It would also have some knowledge of the domain and get notified when loaders get added/removed to the domain so the caches in the pools can be invalidated. There will probably be a bit more to it than this, but this is the basic idea. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/543921#543921] Start a new discussion in JBoss Microcontainer Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]