Esteban C Borsani

+1 This may be the way to go: http://www.reddit.com/r/programming/comments/p7lgl/sql_pagination_in_constant_time_using_the_seek/ Edit: Nevermind, that method has several issues. Works fine for infinite scrolling, though.

IIRC, about 400ms is the compilation itself. The culprit is `unicodedb`, the unicode data tables take that long to compile. IC should fix that. `nim c -d:danger tests/tests.nim` will run...

> that seems exactly like the kind of thing where a vmhook would help, assuming it indeed is a bottleneck, eg proc unicodeTypes*(cp: Rune): int = has simple input/output types...

Are you concerned about the tests being slow, or about nim-regex being slow at CT? It's not the same, because the current APIs need to be tested at CT, so...

What I mean is that API will compile the regex at runtime every time it's called, when called at runtime.

> What I mean is that API will compile the regex at runtime every time it's called, when called at runtime. I think this can be workaround if we can...

> ```nim > const r: CtReg = re"\w+" # now pkg/regex doesn't need to deal with caching, it's user responsability > ``` Is `CtReg` a complex type? I thought vhmhook...

This can be easily implemented without even touching the parsing. Just convert the flags into their string representation and prepend them to the regex. The question is, you find this...

> Remembering that ?m makes the regex multi-line becomes difficult when you use multiple languages (or it does for me at least). That should not be a problem with PCRE...

I'd say, don't use that API. Instead of `m.group(0, text)` do `text[m.group(0)[0]]` which at least you can explain as "`m.group(0)[0]` will return a slice of boundaries for the first repetition...