On Thursday 24 November, Donovan Baarda wrote: > I don't know if this will help, but in my experience compiling re's > often takes longer than matching them... are you sure that it's the > match and not a compile that is taking a long time? Are you using > pre-compiled re's or are you dynamically generating strings and using > them? It's definitely matching time. The res are all pre-compiled. [...] > > A quick look at the code in _sre.c suggests that for most of the time, > > no Python objects are being manipulated, so the interpreter lock could > > be released. Has anyone tried to do that? > > probably not... not many people would have several-minutes-to-match > re's. > > I suspect it would be do-able... I suggest you put together a patch and > submit it on SF... The thing that scares me about doing that is that there might be single-threadedness assumptions in the code that I don't spot. It's the kind of thing where a patch could appear to work fine, but them mysteriously fail due to some occasional race condition. Does anyone know if there is there any global state in _sre that would prevent it being re-entered, or know for certain that there isn't? Cheers, Duncan. -- -- Duncan Grisby -- -- duncan at grisby.org -- -- http://www.grisby.org --
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4