After releasing Xdebug 2.8.1, which I mentioned in last month's update, at the start of the month, more users noticed that although I had improved code coverage speed compared to Xdebug 2.8.0, it was still annoyingly slow. Nikita Popov, one of the PHP developers, provided me with a new idea on how to approach trying to find out which classes and functions still had to be analysed. He mentioned that classes and functions are always added to the end of the class/function tables, and that they are never removed either. This resulted in a patch, where the algorithm to find out whether a class/function still needs to be analysed changed from from O(n²) to approximately O(n). You can read more about this in the article that I wrote about it. A few other issues were addressed in Xdebug 2.9.0 as well.

In the May update I wrote about resolving breakpoints. This feature will try to make sure that whenever you set a breakpoint, Xdebug makes sure that it also breaks. However, there are currently two issues with this: 1. breaks happen more often than expected, and 2. the algorithm to find lines is really slow. I am addressing both these problems by using a similar trick to the one Nikita suggested for speeding up code coverage analysis. This work requires quite a bit of rewrites of the breakpoint resolving function, and hence this is ongoing. I expect this to cumulate in an Xdebug 2.9.1 release during January.

I have wanted to learn Go for a while, and in order to get my feet wet I started implementing Xdebug's bundled debugclient in Go, and at the same time create a library to handle the DBGp protocol.

The main reason why a rewrite is useful, is that the debugclient as bundled with Xdebug no longer seems to work with libedit any more. This makes using debugclient really annoying, as I can't simply use the up and down arrows to scroll through my command history. I primarily use the debugclient to test the DBGp protocol, without an IDE "in the way".

The reason to write a DGBp library is that there are several implementations of a DBGp proxy. It is unclear as to whether they actually implement the protocol, or just do something that "works". I will try to make the DBGp proxy that I will be working on stick to the protocol exactly, which might require changes to IDEs who implement it against an non compliant one (Komodo's pydbgpproxy seems to be one of these).

This code is currently not yet open source, mostly because I am still finding my feet with Go. I expect to release parts of this on the way to Xdebug 3.0.

Support through the Business Supporter Scheme continues to trickle in.

This month's new supporter is Strategery. Thanks!

If you, or your company, would also like to support Xdebug, head over to the support page!

Besides business support, I also maintain a Patreon page and a profile on GitHub sponsors.

The PHP Internals News has been on hiatus since the PHP 7.4 release, but it will return in January.