Capture::Tiny::capture has increasingly long 'start' delay

[henry2cox]

After some debugging I found that the performance issue described in https://github.com/linux-test-project/lcov/issues/228 is because the 'capture' call has an increasingly large startup overhead - seeming to increase without limit.

My use can be seen near line https://github.com/linux-test-project/lcov/blob/master/bin/geninfo#L1049C14-L1055C19

my $childInfo; <---- collect time delay from here my ($stdout, $stderr, $code) = Capture::Tiny::capture { $trace_data = undef; <---- to here # ... call function to do actual work here };

In my sandbox, I added calls to Time::Hires::gettimeofday() at the locations above and merely subtract to find out how long it takes to get started. For the first few calls: zero/not measurable. But then the delay gets longer and longer:

• 0.01s after 50 calls
• 0.02s after 60
• ...and slowly increasing on each subsequent call:
  • 0.77s after 500 calls
  • 1.71s after 1000 calls
  • 2.22s after 1500 calls
  • 2.29s after 1744 calls

I was using perl/5.22.0 and Capture::Tiny/0.44.

What am I doing wrong/what should I do differently?

You can observe the effect by running lcov -c ... or geninfo .... to extract coverage data from a moderately large project.
The above numbers come from measuring coverage of the llvm (compiler) implementation as it compiles a 'hello.cpp' application. The user example in the lcov bug report, above, is much larger.

Any help is appreciated. Thanks

Henry

[henry2cox]

I forgot to mention - and it may not be immediately obvious from the code:
Capture::Tiny::capture is called twice in this implementation...the outer call mentioned above and the inner one at https://github.com/linux-test-project/lcov/blob/master/lib/lcovutil.pm#L373C1-L375C7

The observed behaviour looks a lot like a resource leak. Is a nested call to capture supported/supposed to work, or do I need to do this a different way?
If the latter: what mechanism do you suggest? Thanks

[henry2cox]

Tuns out to be issue in my code. Sorry for the false alarm