Adding one of your combinator takes 10 ups away. I've stopped with a second one.

Don't use it. If you want to let only a signal pass you can do this:
Signal wanted is N
Input - N=N
Output - N (count)

Adding one of your combinator takes 10 ups away. I've stopped with a second one.

Well, UPS usage depends on how many signals you have on your control wire if using whitelist mode and how many you have in your input wire if using blacklist mode. To be technical, it's a O(n) operation for each combinator every tick, where n = #control signals if whitelist or n = #input signals if blacklist.
So far I have not found a way to be more performant than O(n) for the operation, but I will surely update if I find a better way.

Don't use it. If you want to let only a signal pass you can do this:
Signal wanted is N
Input - N=N
Output - N (count)

Pretty sure that is not the case where UPS usage is high...
Also, if you need to filter for signals not knowing what is N, but wanting to get N from the circuit network, there is no way without some ticks of delay.
Still, no problems, use it if you wish and if it fits your use case without using up too much UPS.

I will surely update if I find a better way.

A better idea:
1. Create an invisible constant combinator with filtered signals and values of 2000000000000
2. Wire 1 together with input to invisible decision combinator where EACH > 1000000000000 and output EACH
3. Another invisible combinator should subtract 2000000000000

Limitations:
It will fail if there are values above 10000000000000 in input.
But for practical uses this will be enough.

I suggest moving
1000000000000 to settings as "max signal value" and a hint describing the limitation.

Invisible means empty sprite, empty collision box.

This all will result in super mega performanant version - same as vanilla setup, because no "on_tick" is needed anymore.

A better idea:

Hey there, thanks for the idea. I'm not sure I fully understand it though.

1. Create an invisible constant combinator with filtered signals and values of 2000000000000

What do you mean by a constarnt combinator with filtered signals?

Unfortunately, I also saw a significant UPS impact.

This is the design he's describing (expand "Image of Circuit"). I replicated the design and it seems to work quite well. It has the limitation of supporting values up to the arbitrary multiplication/subtraction factor, but I think you could go with something like10E8 and be quite safe.

A better idea:

Hey there, thanks for the idea. I'm not sure I fully understand it though.

1. Create an invisible constant combinator with filtered signals and values of 2000000000000

What do you mean by a constarnt combinator with filtered signals?

I mean a constant combinator which is set to the signals you want to keep after filtering.

Let's start from the very beginning:
Say you have signals in network: copper = -50, iron = 200, stone = 10, wood = -30,
And you want to filter: to keep only copper and iron and get rid of all the rest

You should set constant combinator to
copper = 2000000000000, and iron = 2000000000000.

After that you just wire that combinator and input togather.
This summs them up, so you'll get:
copper 2000000000200+(-50) => 1999999999950,
iron 2000000000000+200 => 2000000000200,
store = 10
wood = -30

Now all this goes (wires) into decider with condition ">1000000000000" and output = each input, so let's see:
copper = 1999999999950 - passes
iron = 2000000000200 - passes
store = 10 - won't pass
wood = -30 - won't pass

So now we have:
copper = 1999999999950, iron = 2000000000200

Ok, the final step: let's put an arithmetic combinator which subtracts 2000000000000 from each and outputs each:
copper 1999999999950-2000000000000 => -50
iron 2000000000200 => 200

So we finally got the output we wanted: iron = 200, copper = -50.
We started with: copper = -50, iron = 200, stone = 10, wood = -30 and now filtered it to iron = 200, copper = -50.

+1

For me I changed the script to every_nth_tick instead of a simple on_tick event since my values are pretty static an update every 60 ticks is more than enough for me and that really improved my UPS back

just change the end of update.lua to have something like the following (you can also create a startup variable to allow for some config as well
script.on_nth_tick(60, onTick)