Another month, another monthly update where I explain what happened with Xdebug development in this past month. It will be published on the first Tuesday after the 5th of each month. Patreon supporters will get it earlier, on the first of each month. You can become a patron here to support my work on Xdebug. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.
In November, I worked on Xdebug for about 30 hours, on the following things:
Matt Brown contacted me a few months ago, suggesting that I should consider cleaning up the design and content of Xdebug’s website. He spend countless hours both redoing my atrocious (and old!) code that powers the website, and creating a new design for it. During November we put this new design online, and I upgraded the server to run PHP 7.4 too. There are still a few rough edges, and there are a few thins I still want to improve, but I believe that the new design (and code!) are much cleaner. Thanks Matt!
I only spent a little time on Xdebug 3 this month, mostly due to travel to speak at conferences. I did finished the modularizing of the Xdebug code base, and now have moved on to cleaning code up and refactoring it even more to continue to make it more maintainable.
Beyond that, I have started to remove a few things from Xdebug as well. I removed the aggregated profiler feature, which was never documented, and prepared an uncommitted patch to remove the
xdebug.remote_handler setting. This setting could only ever have one value (
dbgp), and it seems very unlikely that in the future Xdebug will support other debugging protocols. The underlying code for being able to have more protocols continues to exist. This is mainly because it enforces better design and less coupling between the different parts of Xdebug.
I was right to think last month that it would be likely to have to make a bug fix release. A user commented on Twitter that the code coverage functionality was drastically slower. In Xdebug 2.8 I changed how the coverage functionality remembers which classes and their methods it had already analysed. In 2.7 and earlier, it sets a specific flag on the class entry, but that was always a hack, which stopped working (again) with PHP 7.4. Instead of using that flag, I now use a hash table to do so.
However, I had inadvertently negated the check, so instead of only analysing classes and their methods on the first visit, Xdebug ended up analysing it every single time. The fix for this was therefore small (and embarrassing).
During the testing of this new “fix”, I noticed that code coverage was still a lot slower than in Xdebug 2.7.2, so I did some more research to improve this. Instead of allocating memory to create the hash key, I use stack memory instead.
For Xdebug 3 I have a few further ideas to speed up code coverage.
The bug fix for the performance degradation is the only ticket that made it into Xdebug 2.8.1.
Update: Xdebug 2.8.1 was released on December 2nd (so not actually in November).
I have had further, but minimal, interest for the Business Supporter Scheme that I launched in September.
Truncated by Planet PHP, read more at the original (another 1396 bytes)