Skip to content

Instantly share code, notes, and snippets.

@szydell
Created June 15, 2023 17:26
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save szydell/8c32193add47b3a314f7d705f7144b65 to your computer and use it in GitHub Desktop.
Save szydell/8c32193add47b3a314f7d705f7144b65 to your computer and use it in GitHub Desktop.
blokuje cie bo jestes debil
IIablo — Dziś o 18:38
Hej
szydell — Dziś o 18:39
Hej
IIablo — Dziś o 18:39
odnosnie regexp
.+? dobrze stosowac dla krotkich skokow
czyli np 5 wyrazow bedzie szybciej niz .*
.* skacze od razu na koniec zdania i szuka wstecz
wiec jest szybka dla zawartosci plecaka
ma to sens?
szydell — Dziś o 18:42
I to jest wiedza wynikająca z...?
IIablo — Dziś o 18:43
z mierzenia ile czasu regexp sie wykonuje
szydell — Dziś o 18:44
Ok. Są gdzieś te benchmarki dostępne?
I czemu .*/.+, a nie [a-zA-z ]+, które powinno być jeszcze szybsze? 🙂
IIablo — Dziś o 18:45
https://regex101.com/
regex101
regex101: build, test, and debug regex
Regular expression tester with syntax highlighting, explanation, cheat sheet for PHP/PCRE, Python, GO, JavaScript, Java, C#/.NET, Rust.
regex101: build, test, and debug regex
Nie no, jebnij 10k tekstu
szydell — Dziś o 19:03
Potestowałem. I nie ma to żadnego znaczenia wg. toola, który wklejasz.
Czy daję +, czy * to ilość stepów jest identyczna.
jedyna zmiana, to przejście z . na [0-9a-zA-Z, ]. Co daje zawrotną zmianę w parsowaniu (w moim case) z 8361 stepów na 8359. Także temat kompletnie pomijalny.
Oczywiście musimy zakładać, że biblioteka regexpowa używana w lua jest algorytmicznie w 100% zgodna z pcre, co jest niekonieczne.
szydell — Dziś o 19:10
Ok, jednak akurat to jest pewne. Includuje pcre. To będzie w kwestii kroków ok.
IIablo — Dziś o 19:17
bo zle dodajesz
szydell — Dziś o 19:17
A i sprawdziłem jeszcze debugerem po kolei kroki. Zakres matchowania patternów, tj. skok na koniec i cofanie się, jest identyczny. Testowałem różnice między pierwszym .+ i .* , przed (plecak.
Step 13-21 wyglądają identycznie.
Co źle dodaję?
Typ załącznika: document
message.txt
4.47 KB
To jest test string. Nierealnie długi jak na standardy arki.
IIablo — Dziś o 19:18
^Otwart(y|a|e) .+? (plecak|torba|sakwa|sakiewka|worek)(?: ze? .+)? zawiera (.*)\.$ 51 steps na 5k linijce
^Otwart(y|a|e) .+? (plecak|torba|sakwa|sakiewka|worek)(?: ze? .+)? zawiera (.+?)\.$ 10k steps
szydell — Dziś o 19:19
No to od test stringu zależy, no nie? Pokaż co tam wklejasz, to sobie obejrzę.
I te 2 regexpy, które wrzucasz, to nie są te regexpy, które są w repo.
^Otwart(y|a|e) .+ (plecak|torba|sakwa|sakiewka|worek)(?: ze? .+)? zawiera (.*)\.$
vs
^Otwart(y|a|e) .+ (plecak|torba|sakwa|sakiewka|worek)(?: ze? .+)? zawiera (.+)\.$
IIablo — Dziś o 19:21
no i?
szydell — Dziś o 19:21
Testowałem też sobie z ciekawości
^Otwart(y|a|e) .+ (plecak|torba|sakwa|sakiewka|worek)(?: ze? .+)? zawiera (.*)\.$
vs
^Otwart(y|a|e) .* (plecak|torba|sakwa|sakiewka|worek)(?: ze? .+)? zawiera (.*)\.$
i zachowanie jest identyczne.
*, a + nie zmieniają nic w przypadku stringa, który może się pojawić na arce.
Lista stepów jest pięknie pokazana w debugerze.
IIablo — Dziś o 19:22
marnujesz mój czas ziom
ja ci tlumacze oczywistosc, a ty sie upierasz jak jakis gowniaz
szydell — Dziś o 19:23
Dude. Konkrety. Pokaż mi cokolwiek, co potwierdzi twoją oczywistość.
Na jakim test stringu badasz ten pattern?
IIablo — Dziś o 19:23
blokuje cie bo jestes debil
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment