phpactor is killing my cpu

[akabakass]

Hi,
not sure what's happening, but my cpu burn if I try to use phpactor

this is after less than 1 minute on my file.
I'm using neovim with nvim_cmp and lspconfig. I've installed phpactor through mason and set it up using mason_lspconfig.
here is my setup handler:

  mason_lsp.setup_handlers {
       -- The first entry (without a key) will be the default handler
       -- and will be called for each installed server that doesn't have
       -- a dedicated handler.
       function (server_name) -- default handler (optional)
         -- local capabilities = require('cmp_nvim_lsp').default_capabilities()
         local lsp_config = require("lspconfig")
         lsp_config[server_name].setup ({
           root_dir = function(file_name)
             return lsp_config.util.find_git_ancestor(file_name)
           end,
           -- capabilities = capabilities
         })
       end
     }
   end

nothing fancy here
the scenario to get to the thumbnail is this.
when I open a file, one process pops at 100% on the cpu. I thought of indexing and tried to let it do it's thing with no success. it never leave. when i try to type something, everytime the completion pops up, a new process is created which also uses 100% cpu.
so just typing a few words gets to the situation above.
and even when I quit neovim, all the processes stays here and I have to kill them manually.
Any clues on what is happening?
Tell me if you need anything else to diagnostic this
Cheers

[dantleech]

have you enabled Psalm or Phpstan? and which version of Phpactor are you using? phpactor status

you can also set this option to false to prevent Phpactor's own diagnostic process from spawning https://phpactor.readthedocs.io/en/master/reference/configuration.html?highlight=annotation#language-server-diagnostic-outsource -- if that fixes the prcoess issue, then likely the main process will be blocked, but at least we know what's to blame.

[akabakass]

I don't have a lot installed:

here is my status:

setting outsource to false only use one process now, but it is still stuck at 100%, and is not killed when quitting neovim.

[dantleech]

ok, the Psalm/PHPStan extensions wouild be enabled in .phpactor.yml but if we're already solving it with outsource=false then it's probably not those.

the version you are using is from 10 weeks ago though, can you update to the latest development version (master) or are you using the PHAR?

Also I assume you are starting Neovim in the root of your project? If not try that.

[calebdw]

I've also had periods when phpactor just runs away and becomes painfully slow and I have to manually kill the processes. I also work on a large codebase though.

I use phpactor with phpstan

[akabakass]

ok, the Psalm/PHPStan extensions wouild be enabled in .phpactor.yml but if we're already solving it with outsource=false then it's probably not those.
the remaining process is still stuck at 100% cpu usage, outsource=false is only partially hiding the issue I reckon.

the version you are using is from 10 weeks ago though, can you update to the latest development version (master) or are you using the PHAR?

updated this morning through Mason to version:
Phpactor dev-master@1dcb8b2c589912ca8712a75c0a214d365de331fc
I removed the outsource = false and still got the same issue.
I tried it on my smaller laptop with the same settings and codebase, and no issue found.

Also I assume you are starting Neovim in the root of your project? If not try that.

I am, but been in or not doesn't change anything for me in that case.

I've also had periods when phpactor just runs away and becomes painfully slow and I have to manually kill the processes. I also work on a large codebase though.

One could say mine is pretty large too. I just tested with a folder with only a few files without an issue.

[webdev23]

Same here, it came abruptly without config change, it was working nicely before, now CPU stuck at 100% .

It looks like it's indexing, after many minutes without actions the CPU slows down a bit to ~10%
But each key types does launch another sub-process, that goes 100%.

Using Phpactor with Helix, PHP 8.3, no composer, linux, all that was working alright few days before, that looks strange to me.

ps aux
machine     1152454 98.4  0.9 168864 69472 pts/3    R+   20:01   0:28 /usr/bin/php8.3 -n -c /tmp/DS3FvY /home/machine/.local/bin/phpactor

[dantleech]

Same here, it came abruptly without config change

can you indicate which version of Phpactor you are using.

---

indexing should be unreleated to multiple CPU cores being maxed out to 100% as the indexer uses only one core.

i'd be more inclined to suspect:

• a large and complicated file
• some problem bug with the class inheritance resolution in phpactor, related to exotic things like "traits", or generics, or possible any other "special" things?

[dantleech]

if I add a 10 second delay to the worker process:

diff --git a/lib/Extension/LanguageServer/Command/DiagnosticsCommand.php b/lib/Extension/LanguageServer/Comman>
index dd644fc8..22d93d5c 100644
--- a/lib/Extension/LanguageServer/Command/DiagnosticsCommand.php
+++ b/lib/Extension/LanguageServer/Command/DiagnosticsCommand.php
@@ -45,6 +45,7 @@ class DiagnosticsCommand extends Command
             );
         }

+        sleep(10);
         $output->write($decoded);

         return 0;
     }

and hit spam key presses I only get 1 or maybe 2 processes (excluding the without-xdebug-respawn):

as I recall only one diagnostic collection process should be spawned per diagnostic provider (e.g. phpactor, psalm php-cs-fxier, phpstan, etc could all spawn one process each)

https://github.com/phpactor/phpactor/blob/388f162c273886db3b46de1d0a9782322732f455/vendor/phpactor/language-server/lib/Core/Diagnostics/DiagnosticsEngine.php#L112

[webdev23]

Hi. Version:

Phpactor 2023.12.03.0@1dcb8b2c589912ca8712a75c0a214d365de331fc

Yes, my code base is huge, but was also previously. If i understand, it may be linked to a particular file created recently?
i wouldn't say it's impossible, because i am not exactly matching standard everywhere in that last project (but it runs well).
i am not sure how i could debug that beside removing file by file? Is there some kinds of logs somewhere?

[dantleech]

try updating to the lastest master version if you can. there may be 2 issues being discussed in this thread. the one I'd consider this issue to be about is the diagnostics processes eating all the CPUs, anything to do with "size of project" and "indexer" is another issue.

[webdev23]

Can't update to master due to some unclear composer error.
Even if "another issue" which I doubt, the result is the same: It's eating all the CPU brutally, without telling why.

Since the last message, in the doubt after your message, I roll all my files into phplint, php-cs-fixer, prettier, and everything is working absolutely alright.

In any cases, an error in a file, even a quadruple loop of GOTO, or the size of the codebase or whatever MUST never create that kind of wild loop of process forks.

I understand that it require some indexing to work, but again, it was alright previously, without config change

[dantleech]

all the CPU brutally, without telling why.

all of the CPUs? or all of a single CPU? that would be the key difference. Indexing will not use all the CPUs and this issue is about all the CPUs.

I roll all my files into phplint, php-cs-fixer

I'm talking about Phpactor shelling out to these processes. If your iussue is the same one being discussed initially in this issue it would be mitigated by the previously mentioned outsource option. Is it?

[webdev23]

Setting outsource to false did solve the CPU problem on my config (no more process forks).

"language_server.diagnostic_outsource": false,

[dantleech]

👍 then need to find out why there is > 1 diagnostic process running at a time.

[calebdw]

Setting outsource to false did solve the CPU problem on my config (no more process forks).

What is the implication of not outsourcing (when would be a case when you want it on and visa versa)? Does phpactor no longer report phpstan diagnostics?

[dantleech]

Implications are Phpactor doing it's own (sometimes rather intensive and blocking) diagnostics work in the main process which is also needs cycles for completion and other language server tasks. If it works for you then great, but if it's spawning > 1 process.for this then it's certainly a bug.

[calebdw]

What happens if you turn it off then? Does phpactor no longer have diagnostics?

[artfulrobot]

I tried phpactor again today (it's been a while), installed through Mason in neovim. It kept spawning php processes that each locked up at 100%ish constantly.

If I start neovim in the project root, it seems I only get one php process. If I start it in a dir bit nested into the codebase, I get lots.

Also, quitting neovim doesn't kill the process(es) - they're still there hogging CPU!

[dantleech]

There is an assumption on my part that neovim be started the root dir of the project, so I'd always recommend that - however it does seem to work pretty well for me when starting in a sub-dir with Neovim, it does not spawn > 1 process.

I am:

• using master
• am using a local checkout of Phpactor
• have outsourced diagnostics enabled (default value)

Any investigation to pinpoint where the problem happens would be appreciated, as suggested above it's very likely to be a bug with the DiagnosticsEngine.php

[artfulrobot]

Thanks @dantleech

I work on plugins inside a bigger project, where each plugin is its own git repo (for example) but the code only makes sense if you look at the entire project. So in my neovim config I set the workspace dir using a function to find the top of the main project, so it's common for me to start in the plugin's dir as that's what I'm working on.

Actually, on more testing, the start dir doesn't seem to make a difference:

From plugin root:
Screencast phpactor 2024-02-22 14-29-57.webm

From whole project root
Screencast phpactor 2024-02-22 14-31-28.webm

~/.local/share/nvim/mason/bin/phpactor --version                                                                                          
Phpactor dev-master@1dcb8b2c589912ca8712a75c0a214d365de331fc

My mason setup:

require('mason-lspconfig').setup_handlers({                                                                                
  default_handler,                                                                                                                                                                                                                                                               
  phpactor = function()                                                                                                    
    lspconfig.phpactor.setup({                                                                                             
      root_dir = function(startPath)
        local rp = (require 'lspconfig.util').root_pattern                                                                 
        for _, pattern in pairs({ ".thisIsDocRoot", ".git", "composer.json" }) do
          local found = rp({ pattern })(startPath)                                                                             
          if (found and found ~= '') then return found end                                                                 
        end
        return nil
      end,
        phpactor = {
          files = { associations = { "*.php", "*.module", "*.inc" } },
        },
    })
  end
})   

(I don't even know if that's the right sort of config structure for phpactor, - the files bit is a straight copy from my intelephense config!)

ooh, the longer you leave it, the more it eats!

Interestingly, on quitting nvim, most of those were killed off. But one remained, still busying itself at 100% CPU until I manually killed it

[artfulrobot]

I managed to add the "language_server.diagnostic_outsource": false, like this in my mason lua config:

require('mason-lspconfig').setup_handlers({                                                                                
  default_handler,                                                                                                                                                                                                                                                               
  phpactor = function()                                                                                                    
    lspconfig.phpactor.setup({                                                                                             
      -- root_dir = ...
      cmd = {"phpactor", "language-server", [[--config-extra={"language_server.diagnostic_outsource": false}]] }
    })
  end
})   

I could then see:

$ ps ax | grep phpac                                                                                                                                                                                                                                  
2403846 ?        Ss     0:00 php /home/rich/.local/share/nvim/mason/bin/phpactor language-server --config-extra={"language_server.diagnostic_outsource": false}                                         
2403853 ?        R      3:26 /usr/bin/php8.1 -n -c /tmp/J4coqL /home/rich/.local/share/nvim/mason/bin/phpactor language-server --config-extra={"language_server.diagnostic_outsource": false}

This did seem to restrict it to one new php process. Again, quitting nvim did not kill that process - I had to kill 2403846 manually.

[dantleech]

hmm, so I can get Phpactor to spawn > 1 diagnostic process, so I'll have a look at fixing that. What is curious is why it takes so long:

can you run

phpactor worse-reflection:analyze path/to/one/of/your/worst/files.php

from the project root and report the time it takes and how many LOC the file has?

phpactor analysis is currently very slow, a complex file can take ~2-3 seconds, and (when triggered via. the langauge server) Phpactor SHOULD kill the diagnostics process if it takes > 5 seconds.

Which makes me speculate if the diagnostics process isn't getting stuck in a loop and can't even be killed for some reason.

The logs should also indicate when Phpactor is killing the process.

[dantleech]

Can we try #2558 (will need composer install afterwards).

[akabakass]

can you run

phpactor worse-reflection:analyze path/to/one/of/your/worst/files.php

[artfulrobot]

I get the same as @akabakass

However I also get

<warning>Warning from https://repo.packagist.org: Support for Composer 1 is deprecated
and some packages will not be available . You should upgrade to Composer 2. See 
https://blog.packagist.com/deprecating-composer-1-support/</warning>                  

Although

% composer --version        
Composer version 2.6.5 2023-10-06 10:11:52        

I also did

git clone 'git@github.com:phpactor/phpactor.git'; cd phpactor; composer install

to check I had the latest main/master; same result.

Then I checked out your PR with:

git checkout origin/gh-2438-do-not-kill-cpis -b gh-2438-do-not-kill-cpis; composer install

And ... same result!

[dantleech]

I get the same as @akabakass

the command is actually worse:analyse

However I also get

about 2 years ago Phpactor included composer 1 to manage its own extensions, but that's not the case now and the dependency has been removed. i can confirm i get no such warning 🤔

[akabakass]

using worse:analyse worked.
here is the result:

~/.local/share/nvim/mason/bin/phpactor worse:analyse index.php 
Analysing files...

    1 [============================]

index.php
+-------------+----------+---------------------------------------------------------+
| range       | severity | message                                                 |
+-------------+----------+---------------------------------------------------------+
| 3608:3617   | ERROR    | Undefined variable "$language", did you mean one of     |
|             |          | "$language", "$languages"                               |
| 4306:4326   | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
| 4382:4402   | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
| 7813:7833   | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
| 8849:8869   | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
| 14935:14955 | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
| 16214:16234 | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
| 16536:16556 | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
| 18402:18422 | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
| 19072:19092 | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
| 19461:19481 | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
| 21274:21294 | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
| 22995:23015 | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
| 23164:23184 | ERROR    | Undefined variable "$current_category_id", did you mean |
|             |          | "$current_category_id"                                  |
+-------------+----------+---------------------------------------------------------+

14 problems in 1,388.2017 seconds with 1,032,313,952b memory

[artfulrobot]

ok, yup mine didn't complete in 10mins so I stopped it.

[dantleech]

ok, so a couple of things:

• we can't "simply" make the diagnostics process faster - it's slow and that needs to be fxied, but it's an epic task that's not happening soon.
• the "throttling" is per file, so 10 files can cause 10 simultaneous processes - we could probably fix that but...
• ... the process should be killed after 5 seconds.

of course iit's going to keep spinning up that 5 second process but it should only "eat" 1 CPU at this stage if you're working on 1 file.

[dantleech]

also can you give an indication of the complexity of a file that takes 10 minutes to analyse? how many lines of code? as if it's not that complex then it can be a bug with Phpactor. A real example would be great.

[akabakass]

the index file tested above is not that bad, 549 lines, many includes though

[dantleech]

i suspect it could be includes, could you try removing/commenting this block?

phpactor/lib/WorseReflection/Core/ServiceLocator.php

Lines 152 to 160 in 3f0d15d

	// enable subset of frame walkers to enable include variables
	// to be merged into current frame
	new IncludeWalker($this->logger, FrameResolver::create(
	$this->nodeContextResolver(),
	[
	new VariableWalker($this->docblockFactory),
	new PassThroughWalker(),
	]
	)),

that should remove include processing

[akabakass]

it was way better, but still long:

~/.local/share/nvim/mason/bin/phpactor worse:analyse index.php 
Analysing files...

    1 [============================]

index.php
+-------------+----------+-------------------------------------------+
| range       | severity | message                                   |
+-------------+----------+-------------------------------------------+
| 188:194     | ERROR    | Undefined variable "$cPath"               |
| 212:218     | ERROR    | Undefined variable "$cPath"               |
| 324:330     | ERROR    | Undefined variable "$cPath"               |
| 1013:1033   | ERROR    | Undefined variable "$current_category_id" |
| 1359:1379   | ERROR    | Undefined variable "$current_category_id" |
| 1762:1774   | ERROR    | Undefined variable "$cPath_array"         |
| 1812:1824   | ERROR    | Undefined variable "$cPath_array"         |
| 2237:2246   | ERROR    | Undefined variable "$language"            |
| 2770:2783   | ERROR    | Undefined variable "$request_type"        |
| 3608:3617   | ERROR    | Undefined variable "$language"            |
| 3871:3884   | ERROR    | Undefined variable "$messageStack"        |
| 3914:3927   | ERROR    | Undefined variable "$messageStack"        |
| 4306:4326   | ERROR    | Undefined variable "$current_category_id" |
| 4382:4402   | ERROR    | Undefined variable "$current_category_id" |
| 4456:4469   | ERROR    | Undefined variable "$languages_id"        |
| 5899:5905   | ERROR    | Undefined variable "$cPath"               |
| 6031:6037   | ERROR    | Undefined variable "$cPath"               |
| 6054:6060   | ERROR    | Undefined variable "$cPath"               |
| 6538:6551   | ERROR    | Undefined variable "$languages_id"        |
| 7247:7260   | ERROR    | Undefined variable "$languages_id"        |
| 7813:7833   | ERROR    | Undefined variable "$current_category_id" |
| 7943:7956   | ERROR    | Undefined variable "$languages_id"        |
| 8849:8869   | ERROR    | Undefined variable "$current_category_id" |
| 11605:11618 | ERROR    | Undefined variable "$languages_id"        |
| 12978:12991 | ERROR    | Undefined variable "$languages_id"        |
| 14265:14278 | ERROR    | Undefined variable "$languages_id"        |
| 14935:14955 | ERROR    | Undefined variable "$current_category_id" |
| 15623:15636 | ERROR    | Undefined variable "$languages_id"        |
| 16214:16234 | ERROR    | Undefined variable "$current_category_id" |
| 16536:16556 | ERROR    | Undefined variable "$current_category_id" |
| 18109:18122 | ERROR    | Undefined variable "$languages_id"        |
| 18402:18422 | ERROR    | Undefined variable "$current_category_id" |
| 18456:18469 | ERROR    | Undefined variable "$languages_id"        |
| 19072:19092 | ERROR    | Undefined variable "$current_category_id" |
| 19149:19162 | ERROR    | Undefined variable "$languages_id"        |
| 19461:19481 | ERROR    | Undefined variable "$current_category_id" |
| 20800:20813 | ERROR    | Undefined variable "$languages_id"        |
| 21274:21294 | ERROR    | Undefined variable "$current_category_id" |
| 21881:21887 | ERROR    | Undefined variable "$cPath"               |
| 22995:23015 | ERROR    | Undefined variable "$current_category_id" |
| 23164:23184 | ERROR    | Undefined variable "$current_category_id" |
| 24218:24224 | ERROR    | Undefined variable "$cPath"               |
| 26051:26063 | ERROR    | Undefined variable "$customer_id"         |
| 26644:26655 | ERROR    | Undefined variable "$currencies"          |
+-------------+----------+-------------------------------------------+

44 problems in 84.3915 seconds with 259,385,768b memory

does that bit of code handle both includes and require? and also the _once versions?

[dantleech]

does that bit of code handle both includes and require? and also the _once versions?

Yes it does... and tbh I'd be happy to remove it or at least make it opt-in.

It would be greatnif you could share/create some code that produces this performance issue.

[akabakass]

our code is oscommerce based (changed a lot since 2006 but the idea is here). here is a similar looking page:
https://github.com/templatemonster/oscommerce/blob/master/theme/admin/specials.php
that one without the includes took ~65 seconds.
and my computer is pretty beefy.

[dantleech]

that file crashes phpactor for me :D

[ERROR][2024-02-28 22:50:40] .../vim/lsp/rpc.lua:734	"rpc"	"/home/daniel/www/phpactor/phpactor/bin/phpactor"	"stderr"	"Fatal error: Allowed memory size of 4294967296 bytes exhausted (tried to allocate 8192 bytes) in /home/daniel/www/phpactor/phpactor/lib/Filesystem/Domain/FilePath.php on line 82\n"

will investigate that.

analysing that file on the CLI isn't too bad though:

 phpactor worse:analyse theme/specials.php                                                  ✘ 130 master
Analysing files...

    1 [============================]

theme/specials.php
+-----------+----------+----------------------------------------------+
| range     | severity | message                                      |
+-----------+----------+----------------------------------------------+
| 151:164   | ERROR    | Function "tep_href_link" not found           |
| 979:995   | ERROR    | Class "splitPageResults" not found           |
| 1099:1117 | ERROR    | Function "tep_gridlist_build" not found      |
| 1536:1558 | ERROR    | Function "tep_get_all_get_params" not found  |
| 1764:1776 | ERROR    | Function "tep_db_query" not found            |
| 1836:1854 | ERROR    | Function "tep_db_fetch_array" not found      |
| 1900:1912 | ERROR    | Function "tep_db_query" not found            |
| 2120:2138 | ERROR    | Function "tep_db_fetch_array" not found      |
| 3394:3410 | ERROR    | Function "tep_get_tax_rate" not found        |
| 3542:3558 | ERROR    | Function "tep_get_tax_rate" not found        |
| 3602:3619 | ERROR    | Undefined variable "$specials_content"       |
| 3623:3646 | ERROR    | Function "tep_product_block_build" not found |
| 4320:4337 | ERROR    | Undefined variable "$specials_content"       |
| 4763:4785 | ERROR    | Function "tep_get_all_get_params" not found  |
+-----------+----------+----------------------------------------------+

14 problems in 7.2585 seconds with 55,833,960b memory

incidentally disabling the IncludeWalker reduces this to 1.5 seconds.

[dantleech]

ok, it crashed for me initially because Neovim (as per the lsp config was using composer.json) for root detection and I had composer.json in the directory containing all of my projects, and the linked repo has no composer.json - so Phpactor was trying to index ALL of my projects.

I git cloned the oscommerce project above and open Neovim in the root of that repository. I can then open specials.php... and it's fine for me, CPUs are fine, nothing at 100%, nothing is going crazy.

[akabakass]

ok, just tried it with the repo cloned, and I get about the same as you, ~5 seconds for specials, and 23 seconds for index.php, which is not that bad.
So there is something with our version (it has 20 years of modifications) I'm not allowed to share our code unfortunately.

[dantleech]

yep, 21 seconds for index.php with the IncludeWalker, 4 seconds without. I think disabling/optimising that walker is already something that could improve this situation.

[artfulrobot]

Sorry for asking a noob question, but with that 'oursource' option - what does it outsource it to? Is that what php-stan is for?

[dantleech]

Sorry for asking a noob question

As previously hinted at it shifts its own diagnostics work to a separate process to avoid blocking the main process. PHPStan and Psalm also provide diagnostics to Phpactor, but these are always in separate processes.

[dantleech]

I've disabled the include walker in #2538 - as it didn't actually seem to work in anycase and I didn't want to burn time on it. I noticed also that we lint as soon as "keys are pressed" - when it would make more sense to start linting after a period of inactivity (e.g. 1 second), the current mechanism is optimistic but quite wasteful, maybe introducing a "i'm still typing" delay would help.

[dantleech]

can you try the following and composer install:

#2584

this changes the behavior to only lint the document after the "user is idle" and should also prevent > 1 document being linted at the same time.

with this and the removal of the include walker I'm hopeful this issue could be resolved 🤞

[akabakass]

here are the results with #2584

./phpactor/bin/phpactor worse:analyse index.php 
Analysing files...

    1 [============================]

index.php
+-------------+----------+-------------------------------------------+
| range       | severity | message                                   |
+-------------+----------+-------------------------------------------+
| 188:194     | ERROR    | Undefined variable "$cPath"               |
| 212:218     | ERROR    | Undefined variable "$cPath"               |
| 324:330     | ERROR    | Undefined variable "$cPath"               |

...

+-------------+----------+-------------------------------------------+

44 problems in 149.1917 seconds with 436,416,032b memory

[dantleech]

Is it better? The main thing is that it should not kill all the CPUs and only one CPU should be occupied and it should be significantly faster above due to not processing includes

Also not sure how it can take 149 seconds on one file without the include processing.

[dantleech]

I'm closing this now as I hope that Phpactor will no longer nuke all the CPUs and it should be faster now we've disabled the Include walker.

Phpactor can be very slow in some files but it should never take 149 seconds on any file! The oscommerce example takes 5 seconds for me on index.php (which is still far too slow). Please raise a new issue to discuss specific cases.