Community
Participate
Working Groups
Build ID: M20090211-1700 Steps To Reproduce: Calling the method resolveType on bytecode classes with a bytecode class name as a parameter is extremely slow. Example: envClass.resolveType(String className) For envClass -> class Attributes className -> java.lang.Object Performance (in milliseconds): Eclipse 3.3.2 -> 0 Eclipse 3.4.2 -> 124 Eclipse 3.5M6 -> 125 More information: In our project (where all bytecode classes are parsed) this results in a performance decrease of 1000%! The exact same code takes 20 seconds in Eclipse 3.4.2 but only 3 seconds in Eclipse 3.3.2 ! The bottleneck is resolveType(String name). The attached spreadsheet contains all resolveType(String name) method calls for java.lang.* and the performance comparison between Eclipse versions.
Created attachment 132777 [details] org.eclipse.jdt.core.IType.resolveType(String) Performance analysis for java.lang.*
(In reply to comment #1) > Created an attachment (id=132777) [details] > org.eclipse.jdt.core.IType.resolveType(String) Performance analysis for > java.lang.* Would it be possible to attach a text report (comma separated values). I am having trouble opening the attachment with both lotus symphony and MS excel. Thanks!
(In reply to comment #2) > (In reply to comment #1) > > Created an attachment (id=132777) [details] [details] > > org.eclipse.jdt.core.IType.resolveType(String) Performance analysis for > > java.lang.* > Would it be possible to attach a text report (comma separated values). > I am having trouble opening the attachment with both lotus symphony > and MS excel. Thanks! Also if you have the code snippet that you used to gather these measurements and it is shareable, please do share - thanks.
Created attachment 133312 [details] Performance (Text) A plain text version of the Excel file.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Created an attachment (id=132777) [details] [details] [details] > > > org.eclipse.jdt.core.IType.resolveType(String) Performance analysis for > > > java.lang.* > > Would it be possible to attach a text report (comma separated values). > > I am having trouble opening the attachment with both lotus symphony > > and MS excel. Thanks! > > Also if you have the code snippet that you used to gather > these measurements and it is shareable, please do share - thanks. > I gathered these measurements directly from our projects code. So I don't have a code snippet per se, but I will try to cook one up and post it!
Created attachment 133740 [details] Code snippet that demonstrates the bug. ( Eclipse Plug-in Project) Here is a small Eclipse Plug-in that demonstrates the bug. The attached archive contains the Eclipse Plug-In Project. Simply run the plug-in and select the "Test Bytecode Speed" action from the "Bug 273268" Menu. Hope this helps!
(In reply to comment #6) > Created an attachment (id=133740) [details] > Code snippet that demonstrates the bug. ( Eclipse Plug-in Project) > Here is a small Eclipse Plug-in that demonstrates the bug. The attached > archive contains the Eclipse Plug-In Project. Simply run the plug-in and > select the "Test Bytecode Speed" action from the "Bug 273268" Menu. > Hope this helps! That was helpful, thanks, I'll see what is going on here,
(In reply to comment #7) > (In reply to comment #6) [...] > That was helpful, thanks, I'll see what is going on here, OK, here is the scoop: The "enormous performance problem" you are reporting is actually a legitimate side effect of the fix for the bug# 206597. Behavior prior to that fix (3.3.2 behavior you are measuring) is simply to return null as in this method of BinaryType. /* * @see IType#resolveType(String) */ public String[][] resolveType(String typeName) { // not implemented for binary types return null; } So, it is not surprising that the cost of this operation shows up as zero while the cost of the real and full implementation shows up as a few hundreds of milli seconds. In the light of this, it is not clear that we are staring at a performance problem at all. What is the situation with your own project, is it material at all that you need to resolveType's against BinaryTypes ? After all at 3.3.2 time you were getting a null and if that is NOT impacting your project in any significant way, then you can simply short circuit the call if the IType you have is an instance of BinaryType, thereby eliminating the 1000% performance degradation you are seeing ?
Ok that makes sense. Should have catched it ourselfes, but the part of the code where this method is called is undocumented and around 5 years old. Turns out that null works just as well and thus 90% of the class does absolutely nothing. Thank you very much for the help! Alexis (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > [...] > > > That was helpful, thanks, I'll see what is going on here, > > OK, here is the scoop: The "enormous performance problem" you > are reporting is actually a legitimate side effect of the fix for > the bug# 206597. Behavior prior to that fix (3.3.2 behavior you are > measuring) is simply to return null as in this method of BinaryType. > > /* > * @see IType#resolveType(String) > */ > public String[][] resolveType(String typeName) { > // not implemented for binary types > return null; > } > > So, it is not surprising that the cost of this operation shows up > as zero while the cost of the real and full implementation shows > up as a few hundreds of milli seconds. In the light of this, it is > not clear that we are staring at a performance problem at all. > > What is the situation with your own project, is it material at all > that you need to resolveType's against BinaryTypes ? After all at > 3.3.2 time you were getting a null and if that is NOT impacting your > project in any significant way, then you can simply short circuit > the call if the IType you have is an instance of BinaryType, thereby > eliminating the 1000% performance degradation you are seeing ? >
Verified for 3.5RC1.
