2016-07-21T11:24:08 GwenDragon

Kommt darauf an wie falsch es gemacht wird, damit es lahmt ;)

Deine beiden Beispiele unterscheiden sich ja nur darin, dass die Regex einmal fest codiert ist und das andere Mal als Variable übergeben wird.
Die Regex selbst und das potentielle Backtracking-Problem unterscheiden sich nicht.

Woher kommen die unterschiedlichen Laufzeiten?
Ist eine festcodierte Regex immer deutlich schneller? Ist der Zeitfresser evtl. nur die Zeile my $re = qr(...)? (Die könnte man aus dem Code-Schnipsel c2 auslagern.) Ist es evtl. nur ein Artefakt des Benchmarks, weil bei c2 die Regex-Engine 10000 mal geladen wird, während sie bei c1 nur einmal geladen wird? Kommt die festcodierte Regex dank irgendwelcher Optimierungen besser mit dem dem Backtracking-Problem zurecht? Oder ist der Zeitunterschied unabhängig vom Backtracking-Problem?

Ich habe jetzt leider keine Zeit um das genauer zu untersuchen.

Was mir bei dem verlinkten Artikel noch aufgefallen ist:
1. das Backtracking-Problem könnte man umgehen, wenn man zuerst mit s/\s+/ /g Whitespace zusammenfasst und erst dann Whitespace am Anfang und Ende der Strings entfernt (vorrausgesetzt, das ist an der Stelle zulässig - wenn man mehrfachen Whitespace innerhalb des Strings erhalten muss, geht es natürlich nicht.)
2. das eigentliche Problem liegt im Flow des CMS. Das System ist kollabiert, weil bei jeder Ausgabe der Homepage der problematische Input aus der Datenbank geholt und erst dann der Filter darauf angewendet wurde. Warum filtern die das Zeug nicht einmal bei der Eingabe bevor sie es in die Datenbank schreiben? Das hätte nur bei einem Request zu einer höheren Serverbelastung geführt. Der Server wäre dann evtl. kurzzeitig langsamer geworden, evtl. wäre die Eingabe gescheitert, aber der Server selbst wäre durchgelaufen.