Re^2: Why is Perl suddenly slow in THIS case?

I just realized that my two-step approach is not the same, as it advances \G whenever it would find \d+ even if not followed by R. That may or may not be desireable in the more general PDF parsing code.

Comment on Re^2: Why is Perl suddenly slow in THIS case? Select or Download Code

Replies are listed 'Best First'.
Re^3: Why is Perl suddenly slow in THIS case? by vr (Curate) on Mar 06, 2017 at 11:00 UTC
It makes sense now, with your explanation, thank you. Intuit: trying to determine minimum start position... But isn't this "start position" already determined by `\G`? :) In my case it would be easy. Indirect objects can't happen in content streams, so modified (without first check) `parseAny_in_stream` can be added. It then is called as class method in `CAM::PDF::Content`. On the other hand, the 150 Mb "R"-less streams are probably too rare to justify any trouble making this fix.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Why is Perl suddenly slow in THIS case?
by vr (Curate) on Mar 06, 2017 at 11:00 UTC

It makes sense now, with your explanation, thank you.

Intuit: trying to determine minimum start position...

But isn't this "start position" already determined by \G? :)

In my case it would be easy. Indirect objects can't happen in content streams, so modified (without first check) parseAny_in_stream can be added. It then is called as class method in CAM::PDF::Content. On the other hand, the 150 Mb "R"-less streams are probably too rare to justify any trouble making this fix.

[reply]
[d/l]
[select]