From 34b1f0e8bd4eb289ca81a781dc2c27c71949ecd9 Mon Sep 17 00:00:00 2001
From: garry-ut99 <72945564+garry-ut99@users.noreply.github.com>
Date: Sun, 19 May 2024 13:00:10 +0000
Subject: [PATCH] Added a link to related discussion: "Proceeding wildcards in
 rules"

---
 Filter-Performance.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Filter-Performance.md b/Filter-Performance.md
index fa23ac2..8eeb3b7 100644
--- a/Filter-Performance.md
+++ b/Filter-Performance.md
@@ -80,7 +80,8 @@ Filter above will be treated as a regex-based filter since it starts and ends wi
 
 The trailing wildcard will be dropped, but the filter is now the pattern `/path/to/`.
 
-Source: https://reddit.com/r/uBlockOrigin/comments/mdh9jz/order_of_complexity_for_network_filters/gsfn0xl/
+Source: https://reddit.com/r/uBlockOrigin/comments/mdh9jz/order_of_complexity_for_network_filters/gsfn0xl/  
+Related discussion: [Proceeding wildcards in rules](https://github.com/uBlockOrigin/uAssets/discussions/23751)
 
 ## `removeparam` modifier
 Avoiding `removeparam` from being visited at all is best (by using [narrowing options and being tokenizable](#narrowing-options)), I do hope filter authors will be as carefully as possible when crafting `removeparam` filters as I am careful at minimizing all overhead in the code -- otherwise all the coding efforts are going to waste.