Wedge

I can fully understand that, but on the flip side, it does work exactly how you suggest.

The only downside to checking for any URL-like structure is that you can risk changing things that shouldn't be changed, e.g. the URL that controls the page index injection for ... expansion (which is a known bug in SMF implementations)

Nope, even that works perfectly... :)

Always has, BTW... I think! (IIRC it's always been transformed even when scripts were disabled.)

That's the thing, it normally gets broken because of the partial URL it has that can't necessarily be pretiffied.

How so?

Btw I was mistaken.. I inverted my benchmark results. The svn version is actually a bit faster. Need to dig into this.

I can't remember if the code was changed or not, been so long since I looked. But in SMF's code at least, the page index included a URL with something like %1$d in it as a placeholder for the page or start number, which caused problems in SimpleSEF. I also know that there were problems with Google at one point, scraping content for URLs and seeing %1$d type content and trying to visit it, only to be rebuffed.

- Google: well, it depends if they visit all pages but those in actual links... In our case it's <a data-href> so it shouldn't visit. But we know Google is too curious for its own sake... Anyway it will load the page but point to the correct canonical URL. I can live with that...
- SimpleSEF: if it matches against \d+ only, then I guess it can't find it yes. Wedge matches against more, precisely so that %1$d is taken into account.

Certainly at one time it was matching against anything that looked like a URL, even not in a tags, which is why there were things where the URL was split up.

I don't know what SimpleSEF did in the end, I just know that %1$d or whatever else was in the page index was problematic. But if the PURLs implementation correctly converts it to suit and everything still works as it should, great.

The wizard is in action!!! 400% faster.. :o

For The callback. Which is already very fast ;)
Basically with all my optimizations, purls is now about twice faster overall than before. :) it's already a nice gain. But it's bound to bring some new bugs. Which I'll fix, of course, when they come up!

And it's currently broken, in redirectexit(), when trying to redirect back to a topic, since it redirects back to ?topic=x which causes a redirect loop... return-to-topic currently is broken for me, it saves but subsequently fails to load the page after (where it has returned to the topic)

Yep, yep, I fixed it a couple of minutes ago... (Feeds were ALSO broken for a few dozen minutes, sorry about that.)

It's because I modified PURLs to use references everywhere in filters (rather than just in the $urls to $url loop, also in the filter calling, to avoid passing and returning a 100+-entry array on every call). And I forgot to update redirectexit() to use the new system.

Performance is not noticeably better by doing that, but I made some tests by calling it 10k times and that code block is about twice faster than before. So if you know you're going to modify an array before you pass it, *and* you have lots of entries, references are helpful for performance.

Anyway... So, I also rewrote the topic handling code to use a more efficient regex, in light of my recent discovery on look-arounds.
With all of my optimizations combined, pretty URLs are now about 250% faster than before, and can be as fast as 10 milliseconds for a full topic page with 15 posts! (Before that, it was 0.03s-0.04s on average...)
I don't know if I can optimize it even more, but I'll have a look.

Optimizing board and profiles isn't too exciting BTW -- it wouldn't save a lot.
Also, going through the URL array multiple times definitely doesn't hurt performance. Doing the main preg_replace twice isn't as great, though, but because I've optimized the regex for it, it shouldn't be as much as a problem as it used to be...
I'm pretty hopeful that Wedge's implementation of Pretty URLs is now going to be as fast as it can.

One final note... I rewrote the action code to allow for this kind of URL:

http://wedge.org/pub/bugs/7333/pretty-url-remarks/msg277572/do/something/?in=27

Instead of:

http://wedge.org/pub/bugs/7333/pretty-url-remarks/msg277572/?action=something;in=27

It doesn't seem to create any further issues, and it looks cool. My main concern is that in terms of performance, it's about 3 times slower than currently (the action loop I mean!), because as of SVN, the regex is only run if no match was found earlier, when right now it'll be run every time. (Albeit an optimized regex with, again, the lookaround optimization.)
It's still very fast -- an average on one millisecond to run the function on all URLS -- but I'd like to get some opinions on the URL scheme for this.

:edit: Updated post intro.

I like what you've done with it, it's pretty approachable and friendly in the scheme of things :)