> I've just tested the latest beta releas

Where did you get it?

> My local desktop PhpED was always fine with this issue, but that is a very fast 2D display adapter

I am pretty sure hardware has nothing to do with this problem: a) v10 works great; b) my GPU is good enough. Not to mention that you should not have very fast adapters to redraw IDE status. You don't need 50fps for that. It's clear that redraw is just fine, the problem is in calculation.

> Possibly a computer using something like low performance/power integrated graphics might be slower and see the issue more easily.

I doubt it. Again, since v10 does not have this problem in exactly the same environment, v14 is also expected to perform just fine.

When you use PHPEd locally - is your webserver running in a virtual machine or on Windows host?

I am one of the beta testers.

I didn't say hardware specifically, I said for me remote desktop was a lot slower and that is software. RDP is pretty good but has always had issues with anything that causes lots of screen updates (eg graphics applications like Photoshop).

If you have never turned off hardware acceleration on a Windows video driver, give it a go On a high-resolution screen it KILLS performance for 2D updates. Not saying that is a problem on yours, but I've seen that happen. That is why when you install Windows on a new computer the display is sometimes initially very slow at updating, as it is using the base Windows driver with no acceleration.

We are not arguing that PhpED should not be doing lots of updates of any sort, so of course you shouldn't need 50fps for PhpED. New feature(s) in v14 have introduced an issue and NuSphere are trying to fix it.

My setup is reasonably fast:

* Local computer is Windows 8.1 64-bit (6 cores @ 3.2GHz, 16GB memory) with 3 displays (two at 1920x1200 and one at 2560x1600) using two ATI FirePro adapters.
* Web server is Windows Server 2012 (24 cores @ 2.2GHz, 48GB memory) with Apache (nothing is virtualised)
* Remote desktop server is VMware ESXi (24 cores @ 2.2GHz, 64GB memory) with Windows 7 64-bit VM (4 cores allocated, 12GB memory)
* The web server connects to the ESXi server using a dedicated 1Gb network connection
* My local desktop connects to both servers using a shared 1Gb network connection. I don't use wireless.
* I use the multi-screen configuration for RDP, so all 3 monitors are available on the remote desktop and are running at full 32-bit colour.

My local desktop was not detectably slow with this issue, my remote desktop connection was significantly slow but from what you said, it was not as slow as yours. Maybe the causes of our problems varies, but I believe that for me the slowness was caused by a large number of screen updates and I could clearly see the flickering and redraws on the screen when using remote desktop.

I don't believe that 'calculation' (as in raw CPU processing) was ever an issue. Dmitri hinted that it could be caused by slower network communication between DBG and the web server. In my case, that did not seem to be a problem because my local desktop was fine yet has a slower network connection to the web server. If I understand the problem & fix correctly, it probably both reduces the number of screen updates and also reduces the amount of debugger communication.

Hopefully after further testing the next release will resolve this issue for you

dmitri,

Thanks for improving performance. b14040 debugging is much more responsive.