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