Kiedy ustawienie "perl = TRUE" w "strsplit" nie działa (zgodnie z przeznaczeniem lub w ogóle)?

Question

Właśnie zrobiłem kilka badań porównawczych podczas próby optymalizacji kodu i zaobserwował, że strsplit z perl=TRUE jest szybciej niż bieganie strsplit z perl=FALSE. Na przykład,

set.seed(1) 
ff <- function() paste(sample(10), collapse= " ") 
xx <- replicate(1e5, ff()) 

system.time(t1 <- strsplit(xx, "[ ]")) 
# user system elapsed 
# 1.246 0.002 1.268 

system.time(t2 <- strsplit(xx, "[ ]", perl=TRUE)) 
# user system elapsed 
# 0.389 0.001 0.392 

identical(t1, t2) 
# [1] TRUE 

Więc moje pytanie (czy raczej wariacja na pytanie w tytule) to, w jakich okolicznościach byłoby absolutnie trzeba perl=FALSE (pomijając parametry fixed i useBytes)? Innymi słowy, czego nie możemy zrobić, używając perl=TRUE, które można zrobić, ustawiając perl=FALSE?

Answer 1

z dokumentacją;)

wydajności rozważania

jeśli robisz dużo dopasowywania wyrażeń regularnych, w tym na bardzo długich ciągów, będziemy chcieli, aby rozważyć używane opcje. Ogólnie PCRE będzie szybszy niż domyślny silnik wyrażeń regularnych, a fixed = TRUE jeszcze szybciej (szczególnie, gdy każdy wzór jest dopasowywany tylko kilka razy).

Oczywiście, to nie jest odpowiedź na pytanie, „czy są jakieś zagrożenia zawsze za pomocą perl=TRUE”