RE: Jde-complete performance

Hi Suraj,
 
Do you think that getting all the class info in one call (four lists) instead of using four separate calls, one for each access level, would make a difference?
I have not checked the internals of your code, but I wonder if one call would allow for removing any duplication on the creation of auxiliary data structures.
 
Other ideas, some already discussed:
* The elimination of the Ant classes from the scanned classpath... maybe using a separate classloader for them, that would be a parent to the "real" classloader used by the application, and restricting the class scanning to the internal one...or just a separate Lisp variable for the Ant-less classpath.
I think this is worth investigating, on my system (Ant 1.6.5) it amounts to 44 extra jar files in the classpath, and quite large ones.
 
* "Pre-loading" the cache using Emacs idle cycles. Maybe by loading only a few jar/directories at a time the hit would be manageable. It could be smart by loading classes listed in the current buffer import list.
 
* Moving more of the completion code to Java? Having a less "granular" or higher abstration level interface in JdeUtilities or JdeUsages, and passing buffer context info to that interface instead of asking for bits and pieces of information and trying to "assemble" the final result in the Lisp side. Again, consolidating the logic in the Java side might allow for the elimination of redundant calls and object allocations. That would address the problem listed below.
 
I have to do some profiling myself :-)
 
Regards,
  Nascif
 
 
 
________________________________

From: Suraj Acharya [mailto:[email protected]] 
Sent: Tuesday, April 11, 2006 8:32 PM
To: Nascif Abousalh-Neto
Cc: Javier S. Lopez; [email protected]
Subject: Re: Jde-complete performance


I don't think that the calls to getClassInfo are the bottleneck for jde completition. When I did some profiling some time ago I noticed that a compleition trigged many calls to JdeUtilities.getQualifiedName and JdeUtilities.classExists . This because when you try and complete something like "foo.", JDE first checks if foo could be a classname before it checks if "foo" is a local variable, parameter or class member. I think I sent an email to the list about this, I'll try and dig it up. 

With jde-usages the "*jde-beanshell-scratch*" buffer keeps a log of all the calls to bsh, and the results of the calls. You can use this to see what jde-complete is doing when you try to complete something.

So I hacked up jde-usages-parse-eval-type-of - it is a copy of jde-parse-eval-type-of which reverses the order of these checks when the thing being parsed doesn't look like a class. An older version of this function is in the last release of jde-usages too, you can try it out with the defalias I mentioned earlier. 
(defalias 'jde-parse-eval-type-of 'jde-usages-parse-eval-type-of)

I haven't seen any noticeable speed differences just by using the jde-usages backend (jde-usages-complete-invoke 
-get-class-info)  for completion. What you get instead is reduced memory usage and the ability to get completion for classes even if all their dependent classes are not on the classpath. 


Suraj


On 4/11/06, Nascif Abousalh-Neto <[email protected]> wrote: 

	Ola' Javier,
	
	I think it does read the jar files four times, since different instances are created on local variables for each one of the four calls. 
	
	I noticed the problem with using the Ant/lib classpath. I think it affects jde-usages too.
	Is it possible to look into the original jde-global-classpath *before* doing the getClassInfo processing?
	Or to have a separate variable that holds just the class files that might be explored from the source code? 
	I believe that other features in JDEE use this approach for source paths.
	
	Thanks,
	  Nascif
	
	
	-----Original Message-----
	From: Javier S. Lopez [mailto:[email protected] ]
	Sent: Tuesday, April 11, 2006 11:29 AM
	To: Nascif Abousalh-Neto
	Cc: [email protected]
	Subject: Re: Jde-complete performance
	
	Hi Nascif,
	
	I probably wrote a lot of this code a while back. The numbers of trips can be reduced to one, I am not sure if it buys you much. However, I don't remember the DynamicClassLoader having to read the jar files each time. This should be done only once, per project reload, as it is quite expensive. And it is worse if you are using Ant, all the jars in the ant/lib directory get appended automatically. (But that's a different problem). Something else to consider is that this is a one time deal. Once Emacs has the information it is cached and reused. 
	
	jde-usages is quite fast, I am not sure how it fares when compared to completion. Currently both perform different tasks so it is hard to compare them.
	
	Javier
	
	--
	Javier S. Lopez
	Software Developer 
	Forum Systems, Inc.
	95 Sawyer Road, Suite 110, Waltham, MA 02453 http://www.forumsys.com
	
	
	The information contained in this electronic mail and any attached
	document is the confidential and proprietary business information of 
	Forum Systems, Inc. It is intended solely for the addressed recipient
	listed above. It may not be distributed in any manner without the
	express written consent of Forum Systems, Inc.