While fixing bz #4157 I downloaded the gnome-utils package so I could use the "gcalctool" to use as an example of an rpm package that was downloaded, built and then try to debug it. In the process of debugging I noticed some slowness in the loading of source files when stack frames are clicked on. Especially stack frame #7(gtk.c line #492). (BTW, I was using gnome-utils-2.14.0-3.src.rpm for the test so this could change with other versions.) When clicking on the gtk.c stack frame it takes over 20 seconds on my i686/2GHz P4 machine to bring up that window. The source file for that has 3432 lines of code in the current incarnation of that file. I'm not sure right now where the time is being spent.
Added blockers. It could be parser-related, but that would only cause it to be slow the first time. SOme investigation needs to occur.
It appears the problem is NOT the parser being called too many times. Debug statements show that the parser is being called at the right times.
2007-03-23 Mike Cvet <mcvet@redhat.com> * DOMSource.java (content): Added. String cache of the source code represented by the DOMSource. Addresses #4223. (setContent): Added. (getContent): Added. 2007-03-23 Mike Cvet <mcvet@redhat.com> * SourceBuffer.java (loadFile): Check to see if the source code has already been cached by the DOMSource in use. Addresses #4223.
Those changes made significant progress Mike. Changing between stack frames is only 2-3 seconds on my x86 machine now. Good work there sir!
Closing via comment above. Thanks Rick!