Debugger lags when using DBI or DBIx packages.

[Kenobi-the-2nd]

First off, I would like to thank the author for creating this extension for VS Code. Code is my go-to editor for almost everything and for some time I had been looking for a way to debug perl in VS Code.

However, while the debugger works fine for some perl programs, for others it is extremely slow. In particular, I have noticed that when I add the DBI or DBIx packages to my modules, to step over individual lines of code it takes several seconds (5-10), and it takes even longer (15 seconds or more) for variable and data structure values to load in the "Variables" section in the side bar. The wait time here is long enough to be unworkable. If you could please look into this issue, it would be greatly appreciated.

Some info on my setup:

OS: Windows 10 Pro
Perl: perl 5, version 24, subversion 2 (v5.24.2) built for MSWin32-x86-multi-thread-64int
VS Code Version: 1.41.1

Please let me know if more details are needed. Thank-you for your time.

[Kenobi-the-2nd]

As an update, I found that the issue is not with the DBI or DBIx packages, but with another package that we import in one of our own modules. I do not have any specifics at the moment, as I am still trying to pinpoint what exactly is causing the slowdown. I will report back when I have done some further testing.

[jburton-trg]

Any joy? I thought I had the same problem as very slow code, and use DBI heavily, but since you say it's not that... How about Spreadsheet::XLSX? Mine seems to be fine up until I hit :
$excelIn = Spreadsheet::XLSX -> new ($fileIn);
Then all the variables disappear. They do come back if you wait an age, but long enough to be unworkable.
I have padwalker AND perl-debug installed, can they cause conflicts?

[Kenobi-the-2nd]

@jburton-trg I am also using padwalker, and from my understanding padwalker is used by perl-debug, which is built in to perl. So I would not think that they would cause issues with each other. But I am no expert there, that's just my speculation.

I haven't used the spreadsheet package you mentioned, but I can confirm that the debugger starts to choke when it gets to code involving file handling. I can't name any specific packages off-hand, but it's been my experience in general that both cpan file handling packages and perl's built-in I/O features cause the debugger to slow down significantly. And as you said, more often than not, the variables and call stack completely disappear.

I have also noticed that the debugger will not allow jumping to breakpoints that are more than a couple modules deep. Any breakpoints I place in the sub modules will be grayed out when I run the script. When I hover over one of them, it gives me "Unverified breakpoint". I haven't found out any reasons why this might be happening.

[raix]

I’m not an expert in perl, the vs code extension rely on perldb and padwalker. For perfomance issues it could be interesting to test if using perldb in the terminal is also suffering.

Perldb and padwalker are not consistent across versions nor platforms - I have a gut feeling that it’s not covered by tests as I’ve seen regressions now and then.

From the vs code debugging point of view there is a fair amount of calls to get the variable scopes - this might be expensive in padwalker. (Could be optimized)

For the grayed out break points - this happens if the extension cannot resolve the correct path for the file. (There is currently an issue with spaces in filenames)

In general perldb and padwalker output a Human readable output making things brittle - I’ve tried to counter act with all the test coverage and test matrix - would have been great with a json output instead.

Any help is much appreciated :)