Re^2: Efficient regex search on array table

Well, here are the almost-humorous results.

I was able to use the qr// on the output of the composeRegex subroutine--so the implementation was a cinch. After doing so, I found that my return times hovered around 11 or 12 seconds. I increased the regex complexity--almost no difference to the time. I began to have hope that something had really improved. To see how much difference it had made, I again removed the qr// from the subroutine's output and tried the identical query again....11 or 12 seconds--the same as before.

It was at this moment that I recalled having discovered a "wine" process running rampant and using cpu resources at full throttle earlier this morning, which I had killed, of course. Hah! Sluggish response just might have something to do with who else is hogging the cpu.

And as for MacOSX having a penchant for dependency on "wine," I say it's better to stay away from the inebriating stuff.

Unfortunately, in terms of breaking the 11-second barrier, that has not yet happened.

Blessings,

~Polyglot~

Comment on Re^2: Efficient regex search on array table

Replies are listed 'Best First'.
Re^3: Efficient regex search on array table by kcott (Archbishop) on Dec 16, 2022 at 04:16 UTC
G'day Polyglot, Take a look at the benchmark section (at end, in spoiler) of my "Regex /o modifier: what bugs?" post from earlier today. It may give you some insight into why `qr//` is not providing any efficiency improvement. I suggest writing your own benchmark with `$str` and `$re` more closely reflecting your real code and data. `use_m()` & `as_qr()` would likely be useful for you; `use_o()` may be helpful but that depends on parts of your code that you haven't shown; I don't think `raw_m()` or `raw_o()` are relevant for you. By the way, I had mentioned that I was using Perl v5.36 which could be providing optimisations; what version of Perl are you using? — Ken	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Efficient regex search on array table
by kcott (Archbishop) on Dec 16, 2022 at 04:16 UTC

G'day Polyglot,

Take a look at the benchmark section (at end, in spoiler) of my "Regex /o modifier: what bugs?" post from earlier today. It may give you some insight into why qr// is not providing any efficiency improvement.

I suggest writing your own benchmark with $str and $re more closely reflecting your real code and data. use_m() & as_qr() would likely be useful for you; use_o() may be helpful but that depends on parts of your code that you haven't shown; I don't think raw_m() or raw_o() are relevant for you.

By the way, I had mentioned that I was using Perl v5.36 which could be providing optimisations; what version of Perl are you using?

— Ken

[reply]
[d/l]
[select]