1 Reply Latest reply on Jun 7, 2005 9:03 AM by belaban

    TreeCache.findNode() creates Fqn's unecessarily

      Hi;

      There appears to be an inefficiency in TreeCache.findNode().

      The tmp_fqn variable does not appear to be used at all. It's initialized at the start of the method, but then is recreated in each iteration of the inner for() loop.

      A JProbe analysis of my application using JBossCache has identified this problem as being one of the top sources of object creation (and hence creates a gc problem for me), and also puts Fqn.init<Fqn,Object> in the top 10 as far as method time goes.

      Here's the TreeCache.findNode() method with my suggested changes:

       private Node findNode(Fqn fqn) {
       Node n, child_node=null;
       Object child_name;
       int treeNodeSize;
      // FIXME: next line is unecessary
       //Fqn tmp_fqn=new Fqn();
      
       if(fqn == null) return null;
       if((treeNodeSize=fqn.size()) == 0)
       return root;
      
       n=root;
       for(int i=0; i < treeNodeSize; i++) {
       child_name=fqn.get(i);
      // FIXME: next line is unecessary
       // tmp_fqn=new Fqn(tmp_fqn, child_name);
       child_node=n.getChild(child_name);
       if(child_node == null)
       return null;
       n=child_node;
       }
       return child_node;
       }

      I'm happy to submit a bug through Jira, but thought I'd check here first to see if there was something obvious I've missed.

      In addition, LockInterceptor.lock() is the other major source for Fqn creation. I'm currently analyzing whether another small (but somewhat different) kind of change there would alleviate a similar problem of object creation. Your thoughts are be appreciated.

      Regards,

      Brian.