RE: Jde-complete performance
"Nascif Abousalh-Neto" <[email protected]>
| Newsgroups | gmane.emacs.jdee |
|---|---|
| Message-ID | <[email protected]> |
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.