Help needed on Eclipse Search performance
by Xavier Coulon
Hello,
Pete Muir opened an issue a few weeks ago (https://issues.jboss.org/browse/JBIDE-12224) because he found that the JAX-RS tooling was sometimes taking too much time to build. He also attached a video to show what's happening on his machine: http://screencast.com/t/pHBqxVas4
Now, at the tooling level, here's what's happening: a set of jars are added to the classpath, and as part of the project build, the JAX-RS builder searches for some JAX-RS annotated types or methods in those new jars, using the Search API. Hélas, Eclipse needs to index those jars, which sometimes takes a few seconds.
Now, as opposed to the CDI specification where the jars should have a marker file (META-INF/beans.xml), JAX-RS does not mandate anything similar, which means that the search includes all the jars..
Here's an example of the code that deals with annotated types search (in ws/plugins/org.jboss.tools.ws.jaxrs.core/src/org/jboss/tools/ws/jaxrs/core/jdt/JaxrsAnnotationsScanner.java) :
private static List<IType> searchForAnnotatedTypes(final Class<?> annotation, final IJavaSearchScope searchScope,
final IProgressMonitor progressMonitor) throws CoreException {
JavaMemberSearchResultCollector collector = new JavaMemberSearchResultCollector(IJavaElement.TYPE, searchScope);
SearchPattern pattern = SearchPattern.createPattern(annotation.getName(), IJavaSearchConstants.ANNOTATION_TYPE,
IJavaSearchConstants.ANNOTATION_TYPE_REFERENCE | IJavaSearchConstants.TYPE, SearchPattern.R_EXACT_MATCH
| SearchPattern.R_CASE_SENSITIVE);
// perform search, results are added/filtered by the custom
// searchRequestor defined above
new SearchEngine().search(pattern, new SearchParticipant[] { SearchEngine.getDefaultSearchParticipant() },
searchScope, collector, progressMonitor);
return collector.getResult(IType.class);
}
Do you know any way to reduce the latency at this level ? Is there any trick to improve the speed ?
Thanks in advance
Best regards,
/Xavier
10 years
Re: [jbosstools-dev] Status for VPE/Hibernate 16 July - 22 July 2012
by Max Rydahl Andersen
moving this to jbosstools-dev
>> > ∙ Reproducing JBIDE-11592 - SIGSEGV when tried JBT 3.3.0.Beta2 on Juno;
>> > ∙ Created prototype for eclipse<->browser communication on XULRunner v>2/WebKit/IE - JBIDE-12276;
>>
>> Interesting - what kind of communication ? communication to external process ?
>> It is Eclipse<->IE/WebKit/XulRunner>=4 communication via SWT Browser widget.
>> As you know, now VPE is implemented using JavaXPCOM interfaces to communicate with XULRunner.
>> But theoretically almost everything what we do now, could be implemented using browser.execute() method to invoke JavaScript from Java, and BrowserFunction class to invoke Java from JavaScript. This would make VPE browser independent and allow to support the most recent browsers.
>> So I just created a simple Eclipse editor using these two methods as a proof of concept. This editor allows to change style of selected text from Eclipse toolbar.
>
> It is considerably slower than JavaXPCOM bridge. Using Browser would simplify implementation on Java side, but then we have to do JavaScript part and test it with all browsers that could be Behind Browser.java class.
Doesn't sound fun (neither Speed nor QE tasks).
How big a speed difference are we talking about here? And when ?
Is it just when doing style changes or also when editing ? with webkit there is a more or less native edit mode is there not ?
> I'd rather spend time and ported JavaXPCOM bridge to latest XulRunner build, because it was implemented as build extension and use code generation to get all XPCOM Interfaces mapped in Java, so it looks doable.
XULRunner is going away/dying afaik I know - especially JavaXPCOM and its missing on 64-bit platforms especially. Considering this - is it worth spending time on that ?
> Another option is look though what kind of functions VPE uses out of JavaXPCOM and implement it for WebKit.
How feasible is this ?
/max
10 years
Recommandation: Using a target-platform in your IDE
by Mickael Istria
Hi all,
After some investigations around JBIDE-11726
<https://issues.jboss.org/browse/JBIDE-11726> (Create target platforms
for developer), we have arrived to an interesting result by having
378987 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=378987>
and**JBIDE-12003 <https://issues.jboss.org/browse/JBIDE-12003> fixed, so
that target platform should be much more stable (CI job only publish
them after validating they can successfully be resolved) and having make
progress about JBIDE-11689
<https://issues.jboss.org/browse/JBIDE-11689>, by using "includeSource"
flag on target-platforms.
So if you want to be less surprised by dependencies-related issue, here
is a way to make your IDE use an equivalent target as the one used by
build, without loosing ability to view source:
1. Checkout the build/target-platform folder in your workspace
2. Open *multiple.target* using the target editor
3. Ckick on "*Set as Target"* on the upper-right corner
Then, PDE will rely on this target definition to resolve dependencies
(from Eclipse, Atlassian, SpringSource and other 3rd-party deps we have).
In order to resolve other JBoss Tools stuff, you may want to complete it
with entries from our development update-sites to resolve other modules
if you need, but please don't commit anything to this TP before opening
a ticket to the target-platform component.
Your feedback is welcome on JBIDE-11726.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
10 years
