RE: Jde-complete performance

Good points all, Suraj. 
It is more important to address the correctness problems first, then worry about performance.
 
Regards,
  Nascif

________________________________

From: Suraj Acharya [mailto:[email protected]] 
Sent: Wednesday, April 12, 2006 2:16 AM
To: Nascif Abousalh-Neto
Cc: Javier S. Lopez; [email protected]
Subject: Re: Jde-complete performance


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

	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.


I doubt it, but it won't hurt either. 


	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.


This is a not problem if you use the jde-usages back-end as it only works off the classes in jde-global-classpath.



	* "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.


This might be useful, though it's hard to determine which classes to load. The import list of a class is not exhaustive enough, and loading all the classes in the classpath is not an option. 



	* 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.


Rather then doing this, I think it would be worth it to use some of the semantic analyzer functions to do a better job of guessing the type of the expression before point. I'm happy with the speed of completion with the changes I described earlier, but there's still a lot to be done in the correctness department. Here are some bugs off the top of my head: 

1) jde-parse-eval-type-of doesn't distinguish between methods with the same name but different argument types, it just picks the first one in its list.
2) the check for local variable declarations uses a regexp and is not bounded by the method body, semantic could be used to improve this. 
3) completion in inner classes for the outer class methods doesn't work
4) ditto for the this.ClassName.method syntax in inner classes.

 Suraj