Hi Mike ... the search used for the analysis was only looking at "*.bas" files and only for a single keyword.
Doesn't matter much ... it's still a tool that I enjoy using and might dig more, now that I have a 64bit version.

I recently posted a hyperlink control ( https://bcxbasiccoders.com/smf/index.php?topic=30.0 ) and in
the post I mentioned a tip about using $CCODE and $INCLUDE to easily get a bunch of "C" directly into one's
BCX project.  I tried that same tip today with Fast File Scan, merging the SLRE .h and .c into a single .inc
file and then $INCLUDING it.  It worked out great ... eliminating the need to create a static lib or obj for
SLRE completely ... and it simplified compiling for both 32 & 64.  That's pretty slick ...

Wow, that's quite interesting. I've stuck with 32bit as well simply because i have a lot of 32 bit hardware that still works perfectly fine.

Just taking a guess i would say the type of data and the way it's being processed would have a big impact. I'm sure the whole data alignment thing can play a big part.

Thanks for sharing,

Mike H

I've never felt compelled to leave my 32-bit comfort zone but today I spent some time tinkering
and I thought the results of my project were interesting enough to share with the group.

I was using my Fast File Scan program (https://bcxbasiccoders.com/mrbcx_samples/ffs.zip) and
wondered what performance would be like if I could make it a 64-bit app.  Hence, my journey
down the rabbit hole.

I had to re-educate myself how to create an import library for the SLRE (regex) library but this
time it needed to be a 64-bit version.  After coming up with batch files that create the .lib, .obj,
and ultimately the .exe, it was time to experiment.

The attached images shows the same search ( one with regex enabled and one without ) running
32 & 64 bit.  The timing differences are impressive but a little bewildering.  All I can think is that caching
may have factored into the results.