SebastianThiebaud / STTweetLabel

Deprecated - A UILabel with #hashtag @handle and links tappable

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Major performance increase by shortening URL regex

inorganik opened this issue · comments

I am using STTweetLabel in a UITableView. In my case, there is one STTweetLabel per cell; each one detects three types of hotwords, including URL. I noticed that when I scrolled kind of fast, the performance wasn't that good, the scrolling was jumpy. I have been testing on an iPhone 5s and 6, both showed jumpy scrolling.

By simply changing the URL regex in STTweetLabel.m to a shorter regex, I got a major performance increase. I can scroll super fast and it's super smooth. Here's the regex I used instead:

#define STURLRegex @"(https?:\\/\\/)?([\\w\\-])+\\.{1}([a-zA-Z]{2,63})([\\/\\w-]*)*\\/?\\??([^#\\n\\r]*)?#?([^\\n\\r]*)"

You can test the regex here: http://regexr.com/39p0t

EDIT: please note regex fix below.

Thanks for this information. I will try that and may update STTweetLabel!

I noticed there is one problem with my regex - it allowed spaces. I've fixed it:

#define STURLRegex @"(https?:\\/\\/)?([\\w\\-])+\\.{1}([a-zA-Z]{2,63})([\\/\\w-]*)*\\/?\\??([^#\\n\\r\\s]*)?#?([^\\n\\r\\s]*)"

http://regexr.com/39pe7

There is some issue right now with your regex, until this is fixed I have to move back to the previous regex:
http://regexr.com/39qlp

Has anyone tested using NSDataDetector with NSTextCheckingTypeLink? It would also remove the need for this project to maintain or test for regex, and it would allow the future implementation of other data types (e.g. all those supported by NSDataDetector).

@SebastienThiebaud @inorganik

I forked and branched develop and created 87c8355 implementing NSDataDetector for link detection. I added a workaround so that the test_setTextAndGetHotWords_setTextWithOneEncapsulateLinkWithSpecialCharacters_hotWords test would pass because NSDataDetector will only detect (http://foo.com/?arg=bar) but not (http://foo.com/?arg=bar(baz)).

All other tests pass except test_setTextAndGetHotWords_setTextWithOneLinkWithSpecialCharacters_hotWords because it is my understanding that [] are valid characters per RFC3986, correct?

If this is sufficient I can remove that test and submit a pull request including all the changes.

How did you benchmark the performance previously?

For a future pull request my hope is to be able to use the NSURL object returned from NSDataDetector and pass it back to the detection block so that one could simply call [[UIApplication sharedApplication] openURL:url];. This saves the need for doing any URL parsing or creation yet again in the detection block and allows for easy external app integration; for example, simply including mailto in the allowed protocols would allow "string with email@domain.com" to automatically be parsed into a NSURL object that would open the Mail app without any other application changes. Thoughts?

Update -- after benchmarking (n = 1000) it appears the original regex is faster than NSDataDetector, bummer. Even though the proposed regex doesn't match all cases, just for comparison I also included it:

            user        system    total        real
orig       10.730000   0.110000  10.840000 ( 10.909613)
nsdd       11.290000   1.210000  12.500000 ( 12.603403)
new_regex  4.200000    0.090000   4.290000 (  4.416512)

Interesting... that's pretty cool. Thanks for sharing! To answer your question I didn't technically benchmark it (as you did), I just used it and that was my impression.

A pretty big refactoring is on the way. With some performance improvements.

Awesome Sebastien! When do you think the new version will be pushed? Just found STTweetLabel and am excited to implement it.

3.1.18 is available with a ton of fixes (auto layout, performances)