Community
Participate
Working Groups
The currently callback API reports redundant information. In one call back: - the package, enclosing type name and the type name is part of the path as well. Across calls: - the package name is always a new char array although it is the same for many types (I guess that in average 10 types share the same package name) - the path is always a new String, although parts of it can be shared (for example the container name) Currently the dialog contains code to share these strings again. Without sharing the memory consumption looks as follows: Memory consumption: 4'010'943 characters for 28748 types Memory consumption: 424'106 characters for 3073 types Memory consumption: 241'280 characters for 1721 types Is there a way to already share some of the char[] and strings in the search engine so that we don't create them
1. We can only trust the path to contain the package name, since 'p1/p2/A.java' can be the document name for the type p1.p2.B.M 2. We have the containerPath as a string & each document name is read from the index and is available as a string. These are combined into the documentPath before calling: IndexQueryRequestor.acceptIndexMatch(String documentPath, SearchPattern indexRecord, SearchParticipant participant, AccessRuleSet access) IndexQueryRequestor is an internal search requestor so we can easily add: acceptIndexMatch( String relativeDocumentPath, String containerPath, boolean isJarFile, SearchPattern indexRecord, SearchParticipant participant, AccessRuleSet access); By default, this method (if not overridden) would call the previous method after creating the document name as containPath + jarSeparator of '|' vs. '/' + relativeDocumentPath. Various methods in the searchEngine create their own IndexQueryRequestor and capture the results, usually by calling the supplied TypeNameRequestor. Combined with bug 92264, we could introduce a new API method to TypeNameRequestor, such as: acceptType(int modifiers, char[] packageName, char[] simpleTypeName, char[][] enclosingTypeNames, String relativeDocumentPath, String containerPath, boolean isJarFile) it would call the existing TypeNameRequestor.acceptType() method if not overridden... but in the case when the UI is not interested in the combined path, then it can supply a TypeNameRequestor that implements its own version of this new method. This would let you hold onto our shared containerPath string & each relative documentPath.
We would also need to add onto IJavaSearchScope & AbstractSearchScope since they currently expect to test if the document is accessible using: public boolean encloses(String resourcePath); We could provide a new method: public boolean encloses(String relativeDocumentPath, String containerPath, boolean isJarFile) { String separator = isJarFile ? IJavaSearchScope.JAR_FILE_ENTRY_SEPARATOR : "/"; //$NON-NLS-1$ StringBuffer buffer = new StringBuffer(containerPath.length() + separator.length() + relativePath.length()); buffer.append(containerPath); buffer.append(separator); buffer.append(relativePath); return encloses(buffer.toString()); }
Kent, will this share package names as well accross types. If I have two types - org.eclipse.jdt.ui.Type_One - org.eclipse.jdt.ui.Type_Two then I currently get two callbacks with two different char arrays for "org.eclipse.jdt.ui"
Dirk, I released changes to TypeDeclarationPattern & QualifiedTypeDeclarationPattern... both will now intern the package name char [] before answering it.
Great! This will affect the existing API. Right ?
yes it will. So do we want to add the new API?
Philippe/Dirk, do we want to add the new API?
Kent, after thinking about it a little more I am not convinced anymore that adding another string based API is the right thing to do. If the internals change inside search then we need to add another API to guaruntee optimal object reusages. So I am more in favour of having an API which returns an object (like the type info class in JDT/UI) which contains the necessary information and hides the internals. Since adding such an API is more works and needs some coordination I opt for the following: we don't add new API for 3.1, we will look into a type info API for 3.2 and I will try to blance memory consumption and performance in the current type info implemementation. How does this sound ?
Sounds fine. I think you should not worry about holding onto the path Strings as is. You're probably creating more garbage by dividing them & attempting to share them. The dialog should only be around for 1-5 seconds anyway.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
