PHP 8.0.0+3 still slow on Windows10

[Ruud]

Issue Summary

Hi all!

I am testing an existing site on PHP 8.0.0 (+3) but all request are still very slow in comparison with the same site on PHP 7.4.1

I found this older thread =>

PHP 8.0 is very slow on Windows (still)

Issue Summary As per this same unresolved, old thread: Put it simply that any sites running PHP 8.0 are painfully slow, whereas any sites running lower PHP versions are fast. I’ve tried creating new sites and alternating versions on existing sites and the results are always the same. There is clearly something bottlenecking the performance of sites running PHP 8.0 on Windows. This is a huge shame as many sites need to take full advantage of this version of PHP, particularly now that many ho…

Which discusses the exact same problem and I hope this would get more feedback by now.

Thanks all!
Ruud

Troubleshooting Questions

This happens on all sites

• Are you able to create a new, plain WordPress site in Local and access it in a Browser?

Have not tried, but I expect it to work normally but slow.

Replication

Start an existing site with Local (my version is 6.4.0) and change PHP version setting to PHP 8.0.0

System Details

• Local version: 6.4.0
• Microsoft Windows 10 Pro
• Version 10.0.19044 Build 19044
• AMD Ryzen 5 3600 6-Core Processor, 3600 Mhz, 6 Core(s), 12 Logical Processor(s)

[Ruud]

CC:@ben.turner,@afragen,@elliottmangham,@amjadali,@dvallieres,@TonyGman,@dewitteprins,@davidfw

Quick update on my situation. I found several relevant other posts on this forum which I mention below because they are relevant for how I was able to solve the speed issues =>

• Update PHP 8 lighting service - please
• Install PHP 8 - #8 by afragen
• Xdebug 3.0.0

The gist of it is; XDEBUG3 is now used for PHP8 but the php.ini from LocalWP is not correct and should be changed (thanks @afragen).
To change the php.ini I had to change it in 2 locations =>

1. the php.ini file in the project itself => /conf/php-8.0.0./php.ini.hbs
2. the php.ini in the lightning-services folder => /Users/{username}/Appdata/Roaming/Local/Lightning-services/php-8.0.0+3/conf/php.ini.hbs

My adjustments were as followed =>

xdebug.mode=develop
xdebug.client_port=9003
xdebug.start_with_request=trigger
xdebug.discover_client_host=yes

XDEBUG.MODE=DEVELOP

To get the same xdebug output as I was used to on version 2.9, instead of using xdebug.mode=debug it required xdebug.mode=develop to also get the var_dump overloaded functionality.

This however in turn caused issues with the site shell. Basically the site shell did not work at all.
I found a way to get this fixed by modifying the 2 batch files which are called when opening the site shell.

The locations for these 2 batch files are:

1. /Users/{username}/Appdata/Local/Programs/resources/extraResources/bin/wp-cli/win32/wp.bat
2. /Users/{username}/Appdata/Local/Programs/resources/extraResources/bin/composer/win32/composer.bat

The changes are to add -dxdebug.mode=debug like in this example:

The one remaining issue is that the LocalWP app itself is no longer able to retrieve the WP version from the site.

@ECHO OFF
php -dxdebug.mode=debug “%~dp0..\wp-cli.phar” %*

JIT

I also tried to enable JIT, but was not able to. As soon as you add the

opcache.jit_buffer_size=256M

Or any other size it no longer works.

If someone finds out why and it able to get it working, let us know, love to test the speed with this additional optimization.

Thanks!
Ruud

[ben.turner]

Hey @Ruud – Thanks for all the work digging in and debugging this!

With the latest Local release (v6.4.3), the newer PHP versions (7.4, 8.0, 8.1) have been updated to Xdebug 3.x

Download the latest release as well as update to the latest PHP version (For example, in the 7.4.x line, upgrade from 7.4.1 to 7.4.30)

• Releases - Local

[Ruud]

Hi @ben.turner! Thanks for the update.

I did some checks and found that to get the overloaded var_dump() it is still required to change the Xdebug mode to ‘develop’
xdebug.mode=develop

Also, while testing this I noticed that switching from 8.0.22 to 8.0.0 does not actually (seem to) switch to the 8.0.0 version, but instead it remains reporting version 8.0.22 via phpinfo() and on the command line.

[ben.turner]

@Ruud

while testing this I noticed that switching from 8.0.22 to 8.0.0 does not actually (seem to) switch to the 8.0.0 version, but instead it remains reporting version 8.0.22 via phpinfo() and on the command line.

Ahh yeah, that makes sense. I think Local’s logic defaults to the most recent minor version – it wasn’t really designed to switch between patch versions. If you really need to go back to 8.0.0, then you’ll need to delete (or temporarily rename) the folder that has the 8.0.22 binary.