I figure that other thread is getting a bit lengthy and wanted to highlight this separately. I've started my investigation of refactoring my code to use WWRegEx instead of Craig Boyd's RegExp.fll. Using the same source string (~270k, 873 lines) and filter values, and comparing the output, which is identical, I get these results:

FLL
Started 57638.932
Finished 57638.940
Elapsed time in seconds: 0.008
--  
wwRegEx
Started 57638.957
Finished 57639.007
Elapsed time in seconds: 0.050

From a practical perspective, both are lightning fast. Having said that the FLL is an order of magnitude faster. At this point I'm also skeptical that the FLL is the root cause of the memory leak but now I'm going back to the other thread. 😃

wwRegEx currently uses the Shell RegEx objects. The object itself is probably pretty fast, but the COM interface adds overhead in short order calls that's going to be noticable. Incidentally this likely will also be a problem for wwDotnetBridge as that too is making COM calls into .NET but I suspect the RegEx is going to be much more efficent so it may be a wash.

+++ Rick ---

I've been able to setup some instrumentation logging. The FLL is significantly faster in the context of how one of my pages is using RegEx.

03/28/2025 12:32 PM: regEx mode is VB
03/28/2025 12:32 PM: Start scan -     45155.666
03/28/2025 12:32 PM: End scan -     45162.039
03/28/2025 12:32 PM: Total time is:          6.373
03/28/2025 12:34 PM: regEx mode is CB
03/28/2025 12:34 PM: Start scan -     45243.878
03/28/2025 12:34 PM: End scan -     45244.600
03/28/2025 12:34 PM: Total time is:          0.722

In this case it's looping through a cursor with 300 rows and building the necessary html/memvars to display a tabular list. Time to see how I can refactor that. If it's the object creation itself I should be able to make that faster.

Creating the global regex object and using that more than restores performance order to my universe. It's actually slightly faster. 😃

03/28/2025 01:55 PM: regEx mode is VB
03/28/2025 01:55 PM: Start scan -     50134.591
03/28/2025 01:55 PM: End scan -     50135.315
03/28/2025 01:55 PM: Total time is:          0.724
03/28/2025 02:00 PM: regEx mode is CB
03/28/2025 02:00 PM: Start scan -     50450.195
03/28/2025 02:00 PM: End scan -     50450.941
03/28/2025 02:00 PM: Total time is:          0.746

FYI the wwGetRegexObject util function is not in your online docs. I realize it's a variation on a theme but thought I should mention.

I added another function called wwGetWwregEx() into wwRegEx.prg (rather than in wwUtils.prg) mainly for consistent documentation purposes. Both work. The wwGetRegEx() method is actually internally used wasn't really meant to be public.

Apparently I'd come to the same perf conclusion that most of the overhead was in the COM object creation not the actual COM calls.

+++ Rick ---

I'm not seeing that in wwRegEx?

Which is why I referred to the wwUtils one.

Rolled out my refactor on Friday afternoon and so far no out of memory errors but it's way too soon to declare victory.

That's because it's not in your version 😄

I've made the change and it'll be in the next update release.

+++ Rick ---