[Java lista] Pattern.compile bug (jdk 1.5)

[Marai Laszlo]

On Fri, 29 Feb 2008 09:25:22 +0100 (CET)
OSTYÁNI Péter <panteros at dev-labs.com> wrote:

  Hali!


> > Talalkoztatok ti olyannal, hogy egy hosszu regexnel a Pattern.compile
> > iszonyatosan lelassul? Nalam egy olyan 6-700 karakter hosszu regexnel
> > lesz kivarhatatlan (1-2 percnel tobbet nem volt turelmem varni).
> Azért én nem merném rögtön azt állítani, hogy ez bug.
> Nem tudom mi lehet a különbség a regex feldolgozásban a két

Hat en sem allitanam, hogy bug, ha az 1.6-ban nem mukodne jol.

> jdk között, de nekem egy 6-700 karakteres regexp eleve
> abnormálisnak tűnik.

36 db vesszovel elvalasztott egesz szam (marmint a peldaban, ami
megfekszik), ebbol egy mezot 15 karakter ir le + a vesszo. Szerintem ez
annyira nem durva.

> Én megpróbálnám azért átszervezni valahogy.
> Csináltam már érdekes dolgokat regexppel, de többszáz
> karakteres mintát soha nem próbáltam összefűzni, valószínűleg
> nekem ezért nem tűnt fel a sebességkülönbség.
> Azért arra is kíváncsi lennék, hogy egy ilyen bonyolult
> feldolgozáshoz mennnyi erőforrás szükségeltetik.

Semmi kulonos. 1.6-tal pikk-pakk mukodik a 2GHz koruli asztali gepemen.
Fel sem tunt a problema, amig meg nem probaltam 1.5-on. 

Meregettem egy kicsit a fenti peldaval, es ugy tunik, mintha sikerult
volna egy 2^n futasideju algoritmust belerakni az 1.5-os jdkba. A
([+\\-]?[0-9]+)?, patternt 20-nal tobbszor egymas melle pakolva (21, 22,
23) szepen mindig 2x-esere no a Pattern.compile futasideje (25x veve
2.5 sec, 28x veve 10 sec). Az 1.6-tal gyonyoruen megy akar 10000
ismetlessel is (165 ms!!!), csak a stack meretet kell jo nagyra
(10M) felhuzni, mert rekurziv az algoritmus.

A feladat egyebkent nem bonyolult, lenyegeben CSV adatot kell elemeire
bontani, ahol az egyes mezok kulonbozo tipusuak lehetnek (String, egesz,
lebegopontos, datum, stb.) 

Persze meg lehet oldani ugy is, ciklusban vegigbohockodik az ember a
Matcher.find( int ) metodussal, de azert nekem ugy egybe jobban tetszett
volna :).

  atleta