Slow on 3/4 asterisks in Filter Bar

I was using FlatView in conjunction with Filter Bar. Some of my files contain several period-charactes ("."), for example: this.is.an.example.txt.
I was trying to find certain files and realized I need to use two asterisks in order to find them. However, when using 4 (or perhaps 3) asterisks, DOpus becomes unstable. The amount of files in the flat view was not unusually high and flat view / filter bar work very fast otherwise, instantaneously almost.

(side note: this has been a topic elsehwere already, but CTRL+arrow keys would be helpful to navigate within the Filter Bar text field.)

There is more weird behavior:
some of my files are named e.g.
example.blablaba.todo.blabla.txt
and some example.blablabla.possibly.todo.txt

when i use flatview in conjunction with filter bar, a second location column in addition to the relative location column will show up at the rightmost side, if, and only if, I type
"poss"
, and the same happens with
"tod"

it does NOT show up when I only type "to", or only "pos"

EDIT: (--deleted edit comment, not relevant--)

I am aware using "." is not a smart choice for file names, but these are "legacy" files from long ago.

the solution to the second issue is to uncheck "include columns from other matching formats" in folder formats, for Flat View format.

What is meant by "crash" and "unstable" here?

Does the program actually crash (as in stop running entirely, with all the windows vanishing, after any crash report dialog is dismissed), or is it just taking longer than you expected, or not giving the expected results?

it became unresponsive and I think CPU was high. This might still mean it was "calculating heavily" for some reason - weather or not that is normal I do not know. I did have to kill it in task manager.

OK, that is not a crash. Terminology matters a lot here!

I'm a bit lost as to the actual problem/symptoms/cause, as the thread discusses several different issues now. (Please don't do that; it's very hard to follow and we use URLs for issue tracking as well.)

If you make some process snapshots while the delay is happening, we can probably use those to see why it's taking a long time, and if it's getting stuck somewhere or just hitting a situation that is very slow (and potentially could be sped up, once we locate it, assuming it's in Opus itself).

my guess was that it might have to do with this, but I might be completely wrong:

I think I will first change options of FlatView pertaining to the search mask and see if this remains an issue in practice - I don't want to burden anyone with this. I just wanted to mention it in case this is important in which case you might be able to reproduce.

That shouldn't be a factor.

I changed the settings after reading up on them.

It might be that as a result, the issue will no longer occur.

I am sharing the previous setting (where the problem occured; I am very, very --- practically 100% -- sure these were the settings), and the settings that I have now set.

former settings:
( ) automatically type (asterisk)
(x) celar automatically
( ) ignore diacritics
(x) match any word
(x) partial matching
(x) real time
( ) regex

new settings:
(x) auto
(x) clear
( ) ignore dia
( ) match any
( ) partial
(x) real time
( ) regex

perhaps this is of some relevance if sb encounters sth. similar.

Process snapshots when the problem is occurring would be the most useful thing here.