Quote:
Thanks for the effort to figure out this kinda workaround but chosing such messy way just to save work (change a script in a later stage of progress) is something I would never do, I would change the script then, regardless amount of work.


The second method i showed should allow a seemless adjustment, the main scripts simply call FILTER3 (call it something better maybe smile ) instead of FILTER, and you could even add code to the front of that alias to make a choice if u think a regular filter well be faster, and just call it, rather than reprocessing the soure file and filter.

IMO it is always going to be better to have created a master routine to deal with things like your filtering data in your scripts than just using a filter itself, this way should a problem arrise as it appears, you can alter the master filtering routine, once, rather than having to eal with indervidual filters scattered through the code. aka Modulization of commands to reduce debugging.

I however yeild to your greater knowledge on your own script as to the ability to intergrate what I admit is only a cludge to solve manifesting problem.

Quote:
The amount wildcards never changed. It remained the same in both fast and extremely slow results. Moving the 'ON' string to position 1,2 and 12 was fast while really slow on most others.


I thinkyou have missed the importantce of how and what the wild card must match to.
The earlier in the filter a exact MATCH/MISMATCH can be detected the faster that line can accepted/abandoned and the next moved on to.
Amagine a filter like this *-*-3-* processing a line like 1-2-3-4
This is a possable order of comparsions taking 14 steps before matching, this is based loosly on the idea that the * consumes as many as possable characters first then starts reducing leaving chracters for the remaining parts of the filter.
Code:
[color:blue]*       | - | *       | -3- | *[/color]
1-2-3-4 |   |         |     |   [color:red]failed[/color]
1-2-3-  | 4 |         |     |   [color:red]failed[/color]
1-2-3   | - | 4       |     |   [color:red]failed[/color]
1-2-    | 3 | -4      |     |   [color:red]failed[/color]
1-2     | - | 3-4     |     |   [color:red]failed[/color]
1-2     | - | 3-      | 4   |   [color:red]failed[/color]
1-2     | - | 3       | -4  |   [color:red]failed[/color]
1-2     | - |         | 3-4 |   [color:red]failed[/color]
1-      | 2 | -3-4    |     |   [color:red]failed[/color]
1       | - | 2-3-4   |     |   [color:red]failed[/color]
1       | - | 2-3-    | 4   |   [color:red]failed[/color]
1       | - | 2-3     | -4  |   [color:red]failed[/color]
1       | - | 2-      | 3-4 |   [color:red]failed[/color]
1       | - | 2       | -3- | 4 [color:blue]matched[/color]


Now this second example is based on the idea that * consumes as few as possable characters and then is added to untill a match is found. And takes just 3 comparisons.
Code:
*       | - | *       | -3- | *
        | 1 |         | -2- | 3-4 [color:red]failed[/color]
1       | - |         | 2-3 | -4  [color:red]failed[/color]
1       | - | 2       | -3- | 4   [color:blue]matched[/color]


*I dont of course know how the wildmatching is done exactly, and if my examples are close or miles off, but they show how a complexe filter with many *'s might be slow because before its validated or not there are 1000's of comparasions to have to check. And this is where i said using the & (1 word) matcher would be much quicker, this of course requieres the tokenseperators to be space however.