Hi,
I am seeing some performance issues with the latest gcc rawhide RPM set. I tried a build of Eclipse with them and it took 650 minutes 42 seconds where it used to take about 20 - 30 minutes (this is just for the bytecode, BTW). I watched the log a bit as it built but nothing stood out to me as taking more time than anything else.
My build did eventually finish, however, so I upgraded to those Eclipse RPMs and tried to run Eclipse. Startup is very slow. I used OProfile to grab some data and put it here:
http://overholt.ca/eclipsestartup-opreport.txt
Then I reset OProfile and grabbed some data while using Eclipse for a few minutes. I have two small projects checked out and I cleaned them, opened a file (which took a very long time), moved around a bit in the file, closed it, and reopened it (which took much less time). Here is the report from that session:
http://overholt.ca/eclipseusage-opreport.txt
The top of both reports is similar. Here's the top of the startup report:
samples % app name symbol name 1814289 28.7922 libgcc_s-4.1.0-20051221.so.1 __deregister_frame_info_bases 1764105 27.9958 libgcc_s-4.1.0-20051221.so.1 add_fdes 1040376 16.5105 libgcc_s-4.1.0-20051221.so.1 size_of_encoded_value 693446 11.0048 libgcc_s-4.1.0-20051221.so.1 classify_object_over_fdes 539261 8.5579 libgcc_s-4.1.0-20051221.so.1 __ucmpdi2
I can get more information if you need.
Thanks,
Andrew
Andrew Overholt writes:
I am seeing some performance issues with the latest gcc rawhide RPM set. I tried a build of Eclipse with them and it took 650 minutes 42 seconds where it used to take about 20 - 30 minutes (this is just for the bytecode, BTW). I watched the log a bit as it built but nothing stood out to me as taking more time than anything else.
My build did eventually finish, however, so I upgraded to those Eclipse RPMs and tried to run Eclipse. Startup is very slow. I used OProfile to grab some data and put it here:
http://overholt.ca/eclipsestartup-opreport.txt
Then I reset OProfile and grabbed some data while using Eclipse for a few minutes. I have two small projects checked out and I cleaned them, opened a file (which took a very long time), moved around a bit in the file, closed it, and reopened it (which took much less time). Here is the report from that session:
http://overholt.ca/eclipseusage-opreport.txt
The top of both reports is similar. Here's the top of the startup report:
samples % app name symbol name 1814289 28.7922 libgcc_s-4.1.0-20051221.so.1 __deregister_frame_info_bases
This is usually called when a library is unloaded. I can't imagine any reason why this might happen when running gij.
The quickest way to find this is to run under gdb and see where __deregister_frame_info_bases is called from.
I have seen this once, and it turned out to be a bug in our interface with the garbage collector. But as far as I am aware little has changed since the last gcc build thath might affect this.
Andrew.
On Thu, 2005-12-22 at 15:01 +0000, Andrew Haley wrote:
Andrew Overholt writes:
I am seeing some performance issues with the latest gcc rawhide RPM set. I tried a build of Eclipse with them and it took 650 minutes 42 seconds where it used to take about 20 - 30 minutes (this is just for the bytecode, BTW). I watched the log a bit as it built but nothing stood out to me as taking more time than anything else.
My build did eventually finish, however, so I upgraded to those Eclipse RPMs and tried to run Eclipse. Startup is very slow. I used OProfile to grab some data and put it here:
http://overholt.ca/eclipsestartup-opreport.txt
Then I reset OProfile and grabbed some data while using Eclipse for a few minutes. I have two small projects checked out and I cleaned them, opened a file (which took a very long time), moved around a bit in the file, closed it, and reopened it (which took much less time). Here is the report from that session:
http://overholt.ca/eclipseusage-opreport.txt
The top of both reports is similar. Here's the top of the startup report:
samples % app name symbol name 1814289 28.7922 libgcc_s-4.1.0-20051221.so.1 __deregister_frame_info_bases
This is usually called when a library is unloaded. I can't imagine any reason why this might happen when running gij.
The quickest way to find this is to run under gdb and see where __deregister_frame_info_bases is called from.
I have both gcc-debuginfo and eclipse-debuginfo installed (correct nvrs) and I set breakpoints in gdb on the top 6 or so symbols in the oprofile report. gdb never appears to hit the breakpoints even though they get resolved and Eclipse starts up incredibly slowly.
Andrew
Hi Andrew,
On Thu, 2005-12-22 at 09:48 -0500, Andrew Overholt wrote:
My build did eventually finish, however, so I upgraded to those Eclipse RPMs and tried to run Eclipse. Startup is very slow. I used OProfile to grab some data and put it here:
Are you sure this data is correct? I see several entries for gnu::classpath::jdwp and as far as I know this code is never actually called yet. If it is I am wondering how that code is triggered.
Cheers,
Mark
On Thu, 2005-12-22 at 16:53 +0100, Mark Wielaard wrote:
Hi Andrew,
On Thu, 2005-12-22 at 09:48 -0500, Andrew Overholt wrote:
My build did eventually finish, however, so I upgraded to those Eclipse RPMs and tried to run Eclipse. Startup is very slow. I used OProfile to grab some data and put it here:
Are you sure this data is correct?
How do I know if it's correct or not? Our current debugging situation is a mess 'cause I'm using OProfile from FC4 (built with gcc 4.0.x) on an FC4 kernel but with rawhide gcc (4.1). It could very well be messed-up oprofile output. I'll try upgrading to rawhide oprofile.
I see several entries for gnu::classpath::jdwp and as far as I know this code is never actually called yet. If it is I am wondering how that code is triggered.
Yeah, I saw that and wondered the same thing myself :)
Andrew
On Thu, 2005-12-22 at 16:53 +0100, Mark Wielaard wrote:
Hi Andrew,
On Thu, 2005-12-22 at 09:48 -0500, Andrew Overholt wrote:
My build did eventually finish, however, so I upgraded to those Eclipse RPMs and tried to run Eclipse. Startup is very slow. I used OProfile to grab some data and put it here:
Are you sure this data is correct? I see several entries for gnu::classpath::jdwp and as far as I know this code is never actually called yet. If it is I am wondering how that code is triggered.
I updated to rawhide oprofile. Here's a new report:
http://overholt.ca/eclipsestartup2-opreport.txt
Andrew
"Andrew" == Andrew Overholt overholt@redhat.com writes:
Andrew> I am seeing some performance issues with the latest gcc Andrew> rawhide RPM set. I tried a build of Eclipse with them and it Andrew> took 650 minutes 42 seconds where it used to take about 20 - Andrew> 30 minutes (this is just for the bytecode, BTW).
I didn't see a note on this list... Andrew Haley and Jakub Jelinek tracked this down to bad debug info generated by an odd combination of events (rpm build flags mixing weirdly with the x86 setup in the compiler triggering some ld bug, or something like that). This will be fixed in a forthcoming compiler rev.
I also heard today about some XML buglet in Classpath that makes part of the Eclipse build take too much memory -- an unbounded cache somewhere. I'll pull the patch in once it is available.
Tom
Tom Tromey writes:
"Andrew" == Andrew Overholt overholt@redhat.com writes:
Andrew> I am seeing some performance issues with the latest gcc Andrew> rawhide RPM set. I tried a build of Eclipse with them and it Andrew> took 650 minutes 42 seconds where it used to take about 20 - Andrew> 30 minutes (this is just for the bytecode, BTW).
I didn't see a note on this list... Andrew Haley and Jakub Jelinek tracked this down to bad debug info generated by an odd combination of events (rpm build flags mixing weirdly with the x86 setup in the compiler triggering some ld bug, or something like that). This will be fixed in a forthcoming compiler rev.
To be honest, we haven't yet proved that this is the real problem -- we won't know until we try the new compiler rev. But IMO it's a likely contender.
Andrew.
On Fri, 2005-12-23 at 17:49 +0000, Andrew Haley wrote:
Tom Tromey writes:
> "Andrew" == Andrew Overholt overholt@redhat.com writes:
Andrew> I am seeing some performance issues with the latest gcc Andrew> rawhide RPM set. I tried a build of Eclipse with them and it Andrew> took 650 minutes 42 seconds where it used to take about 20 - Andrew> 30 minutes (this is just for the bytecode, BTW).
I didn't see a note on this list... Andrew Haley and Jakub Jelinek tracked this down to bad debug info generated by an odd combination of events (rpm build flags mixing weirdly with the x86 setup in the compiler triggering some ld bug, or something like that). This will be fixed in a forthcoming compiler rev.
To be honest, we haven't yet proved that this is the real problem -- we won't know until we try the new compiler rev. But IMO it's a likely contender.
I think this was probably it because things worked great after upgrading to this compiler rev and an Eclipse built with it.
Thanks,
Andrew
java-devel@lists.fedoraproject.org