Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » PHP Development Tools (PDT) » xdebug sometimes slow and path mapping(Eclipse PDT debugging is sometimes slow, but appears not xdebug related)
xdebug sometimes slow and path mapping [message #661510] Thu, 24 March 2011 21:27 Go to next message
Jochen Daum is currently offline Jochen Daum
Messages: 5
Registered: February 2011
Location: Mt Eden, Auckland
Junior Member

Hi,

I experience slow (remote) debugging with Eclipse sometimes and can't get to the bottom of what the reason may be. I also have an issue with path mapping, which I think may be related.

I debug a variety of projects, all on same-machine-hosted local domain names. For example
- project1.local
- project2.example.com

These domain names are defined in /etc/hosts

I also have a current project1 that actually calls project2 through a curl call.

I initiate all debugging sessions through chrome or firefox browser by appending ?XDEBUG_SESSION_START=1 and the curl call uses the same method.

Sometimes/ Regularly, I experience that nothing happens for about 2 minutes until the debugging session starts. Until then, the browser just seems to wait for something. After a breakpoint is reached, I can debug step by step with normal speed. On the next request I have the same wait time.

Here is my experience in regards to things that I have tried:
- shutting down and restarting eclipse: rarely helps
- trying the same url to debug in Komodo: always works (don't get me wrong I like Eclipse better) --> shows its not an xdebug problem
- restarting web server: rarely helps
- waiting 30-60 minutes: nearly always helps
- clearing all cookies of debugged domain: helps in maybe 30% of cases, same with switching browser

The path mapping problem I have is in that sometimes a different file edit view is opened when a breakpoint is reached, even if the file is already open. One file has a workspace specific path, the other one an absolute path.


Can anybody help me with either of:
- resolving the path confusion (hoping this is the root cause)
- using other tools to figure out what happens during the 2 minutes
- recommending other paths of action?





-

Re: xdebug sometimes slow and path mapping [message #661740 is a reply to message #661510] Sat, 26 March 2011 21:24 Go to previous messageGo to next message
Toshihiro Izumi is currently offline Toshihiro Izumi
Messages: 338
Registered: July 2009
Location: Japan
Senior Member
>The path mapping problem I have is in that sometimes a different file edit view is opened when a breakpoint is reached, even if the file is already open. One file has a workspace specific path, the other one an absolute path.

>even if the file is already open
The editor has no sense for source-lookup.
>the other one an absolute path
This means that pdt could not find the debugging-file in the workspace.
Xdebug sends a full-path of the debugging-file to the client(pdt), and then pdt searches it in whole projects (including non-php projects) in the workspace.
When pdt could not find the file, pdt will try to open it by the absolute path. Since it is your local file, pdt can open it.
>sometimes
...?
Re: xdebug sometimes slow and path mapping [message #661795 is a reply to message #661740] Sun, 27 March 2011 18:28 Go to previous message
Jochen Daum is currently offline Jochen Daum
Messages: 5
Registered: February 2011
Location: Mt Eden, Auckland
Junior Member

Hi,

thanks for the quick feedback. I think I understand now and as my workspace is quite big, this was what probably caused the delay.

The whole problem seems to be gone now. I have

- set up path mappings for the projects

- used the same domain name for the curl initiated debug call. I'm assuming there is some connection back from xdebug to the browser that is not served by curl

Kind Regards,

Jochen
Previous Topic:can't set spaces to tabs in Javascript
Next Topic:Plugin : Extending the PHP Explorer?
Goto Forum:
  


Current Time: Fri Apr 18 11:56:30 EDT 2014

Powered by FUDForum. Page generated in 0.02100 seconds