Bugzilla – Full Text Bug Listing
| Summary: | XDebug gets slow after a while | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Florian Hackenberger <f.hackenberger> |
| Component: | PDT | Assignee: | David Kelsey <d_kelsey> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | d_kelsey, petyo_tanchev, zane |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Florian Hackenberger
I found this bug Googling for the same problem. I can confirm the issue. I'm using -Windows 7 x64 -Eclipse Build id: 20100218-1602 -Eclipse IDE for PHP Developers 1.2.20100216-1730 -Apache/2.2.14 (Win32) PHP/5.3.1 -Xdebug 2.1.0 -JDK 1.6.0.140 A quick update. I upgraded to -Eclipse Build id: 20100617-1415 (Helios Release) -PDT 2.2.0 final still the same problem. Try turning on the heap status in eclipse and see if how that behaves over time. To turn on heap status go to Preferences, select General, tick show heap status and press apply. If you terminate all debugging (press Stop) and the restart debugging is it still slow ? If you shutdown PDT and restart PDT does debug remain slow ? Are you using internal or external browser ? Hi Dave, thanks for your reply. >>Try turning on the heap status in eclipse and see if how that behaves over time. Looks like something is leaking: the amount of memory spikes during debug (that's understandable), but then it isn't fully relased afterwards. After a while it's almost all full... Running the garbage collector with that trash icon frees some memory, but it hasn't any effect on the whole environment speed. >>If you terminate all debugging (press Stop) and the restart debugging is it still slow ? The heap is still full after "Terminate and remove". But if I start a new debugging session after that, the debugger seems to be somewhat "fast" again. >>If you shutdown PDT and restart PDT does debug remain slow ? Sorry, I don't know how to restart PDT only. If I restart the whole Eclipse anyway, it becomes very fast again (for a while). >>Are you using internal or external browser ? External. I'm using Apache. It was installed on its own and it's at http://local.megalab.it (my DNS resolves it as 127.0.0.1). Sorry, I misread "internal or external server". The browser ;) is external too. Did you use PDT 2.1 and notice this problem ? It maybe that the leak is inbuilt into some of the common debug infrastructure or perhaps in opening and indexing php files. Can you monitor the heap while using PDT without the debugger for a while using the garbage icon as well). Then perhaps use the debugger and see if it goes slowly. There could be so many places where a possible leak has been introduced :-( Yes, I had the same issue with previous PDT versions too (and previous Xdebug versions too, AFAIRemember). With no debugger active, Eclipse works fine with no leak... but web-activated breakpoints is the main (only?) reason I prefer Eclipse over a plaintext editor with syntax highlighting ;) I have done some looking at the heap while debugging and I don't see a memory leak in any of the xdebug based objects. What I do see however is an increase in objects relating to the editor. Top instance counts after a few runs show 868800 instances of class [Lorg.eclipse.wst.sse.core.internal.provisional.text.ITextRegion; 868797 instances of class org.eclipse.wst.sse.core.internal.text.TextRegionListImpl 868687 instances of class org.eclipse.wst.xml.core.internal.text.XMLStructuredDocumentRegion 578202 instances of class org.eclipse.wst.xml.core.internal.parser.regions.TagNameRegion 568132 instances of class org.eclipse.wst.xml.core.internal.parser.regions.TagCloseRegion 501350 instances of class org.eclipse.jface.text.Region 294164 instances of class org.eclipse.wst.xml.core.internal.parser.regions.TagOpenRegion 285854 instances of class org.eclipse.wst.xml.core.internal.parser.regions.XMLContentRegion 284038 instances of class org.eclipse.wst.xml.core.internal.parser.regions.EndTagOpenRegion 203220 instances of class org.eclipse.wst.xml.core.internal.parser.regions.AttributeEqualsRegion 203220 instances of class org.eclipse.wst.xml.core.internal.parser.regions.AttributeNameRegion 203220 instances of class org.eclipse.wst.xml.core.internal.parser.regions.AttributeValueRegion After another few runs I see 1247639 instances of class org.eclipse.wst.sse.core.internal.text.TextRegionListImpl 1247639 instances of class [Lorg.eclipse.wst.sse.core.internal.provisional.text.ITextRegion; 1247483 instances of class org.eclipse.wst.xml.core.internal.text.XMLStructuredDocumentRegion 830400 instances of class org.eclipse.wst.xml.core.internal.parser.regions.TagNameRegion 815952 instances of class org.eclipse.wst.xml.core.internal.parser.regions.TagCloseRegion 422460 instances of class org.eclipse.wst.xml.core.internal.parser.regions.TagOpenRegion 410475 instances of class org.eclipse.wst.xml.core.internal.parser.regions.XMLContentRegion 407940 instances of class org.eclipse.wst.xml.core.internal.parser.regions.EndTagOpenRegion 291846 instances of class org.eclipse.wst.xml.core.internal.parser.regions.AttributeEqualsRegion 291846 instances of class org.eclipse.wst.xml.core.internal.parser.regions.AttributeNameRegion 291846 instances of class org.eclipse.wst.xml.core.internal.parser.regions.AttributeValueRegion More investigation required. It looks like the leak and performance hit is due to the use of the Debug Output View. If you disable sending information to this then I think you won't see the performance hit. To disable these outputs go to Window-->Preferences Expand PHP then Expand Debug Select Installed Debuggers Double Click on XDebug change Capture StdOut and StdErr to Off click Ok. Let me know if that solves your performance issue Thakyou very, very much Dave!! The solution you proposed works as a charm! You saved both my day and my sanity ;) I have put a fix in now to stop the debug output from filling up during a long web launch debug interaction. Assuming closed. Will be reopened if needed by the community |