Geert De Deckere - 04 May 2007 03:18 PM

Well, seems like we’re done tweaking finally, right?

I like those changes. I just realized one problem with the addition of \n\r\t to the tokenizer: the string is rebuilt with space character so \n and \r and \t will be transformed into spaces. That could be a problem if you imagine this function just before a nl2br(). It might mess some things up for people expecting their newlines, carriage-returns, and tabs to be there.

I suggest just going back to the space tokenizer on the first pass and then see if there are any newlines, carriage-returns or tabs and then on second, third and 4th passes we incrementally replace the other whitespace chars.

I can’t think of any other way of doing it, can you?

Next please. The _str_to_array() function from the Email library desperately cries for help.

system/libraries/Email.php - line 367

BEFORE: 10000 iterations take about 0.3634 seconds

Note that if your email string contains duplicate comma’s (example: “email,,,”) it will create empty array elements right now. This is resolved in the updated function below as well.

AFTER: 10000 iterations take about 0.2024 seconds

sophistry - 04 May 2007 03:56 PM

I like those changes. I just realized one problem with the addition of \n\r\t to the tokenizer: the string is rebuilt with space character so \n and \r and \t will be transformed into spaces. That could be a problem if you imagine this function just before a nl2br(). It might mess some things up for people expecting their newlines, carriage-returns, and tabs to be there.

True. Good Point. Again. The original word_limiter() function does the same thing. Could that be considered a bug? Also note that in case $str is shorter than twice $limit (first lines of function), the original string is returned with all original whitespace. It should at least return the same formatting as in the other case, just for the sake of consistency.

I suggest just going back to the space tokenizer on the first pass and then see if there are any newlines, carriage-returns or tabs and then on second, third and 4th passes we incrementally replace the other whitespace chars.

Could you translate that into some real code? Don’t clearly see where you’re going with that one.

Musing out loud, I wonder if you could shave a few more microseconds by using preg_split() with the PREG_SPLIT_NO_EMPTY flag instead of looping through the items and trim()ing them.

Derek Jones - 04 May 2007 04:33 PM

Musing out loud, I wonder if you could shave a few more microseconds by using preg_split() with the PREG_SPLIT_NO_EMPTY flag instead of looping through the items and trim()ing them.

Great advice! Significant speed boost again and the function becomes even smaller. Regex appear to be faster here! No need for PREG_SPLIT_NO_EMPTY even.

UPDATE: 10000 iterations take about 0.1222 seconds

Ah yes, I guess since you’ll need to be using + to capture whitespace anyway, multiple commas will not create their own array items either.  If you use the PREG_SPLIT_NO_EMPTY flag, though, I believe you can eliminate the trim(), though I would not be entirely surprised if that turned out to be “slower”.

at this rate CI will only be 100k in size and as fast as a static page with all these changes

keep up the good work.

Nice thread! :D

Are these getting updated in the SVN?

Derek Jones - 04 May 2007 05:10 PM

Ah yes, I guess since you’ll need to be using + to capture whitespace anyway, multiple commas will not create their own array items either.  If you use the PREG_SPLIT_NO_EMPTY flag, though, I believe you can eliminate the trim(), though I would not be entirely surprised if that turned out to be “slower”.

I tried.

I had to increase the amount of runs to 100.000 in order to get clear time difference in the benchmarks. Using PREG_SPLIT_NO_EMPTY indeed appears to be slower than the previous version of _str_to_array().

About 1.2236 seconds versus 1.2023 seconds. It is a tiny but consistent difference.

system/libraries/URI.php - line 213

BEFORE: 100.000 iterations take about 1.2795 seconds

AFTER: 100.000 iterations take about 1.1822 seconds

sophistry - 04 May 2007 12:52 PM

I nearly doubled the speed by making some regex mods - one of which I just learned yesterday from Geert (using single quotes)!

function valid_ip_sissy_better($ip)
{
    if (!preg_match( '/^(?:\d{1,3}\.){3}\d{1,3}$/', $ip))
    {
        return FALSE;
    }
    
    $result = ip2long($ip);

    return !($result === -1 || $result === FALSE);
}

10000 reps.
original valid_ip code: 0.3537
old sissy: 0.1865
new sissy: 0.0998

I guess we’re not done with the valid_ip() function yet. Concerning PHP’s ip2long() function, I’ve never used it before but the manual makes it quite clear that this function is not ideal for validating purposes. I quote:

#1 - Because PHP’s integer type is signed, and many IP addresses will result in negative integers, you need to use the “%u” formatter of sprintf() or printf() to get the string representation of the unsigned IP address.

#2 - ip2long() should not be used as the sole form of IP validation. Combine it with long2ip().

#3 - ip2long() will also work with non-complete IP addresses (as Derek Jones mentioned already).

See: php.net/ip2long

These three arguments all mean extra processing overhead. Argument #3 has already been worked around by the regex in valid_ip_sissy_better(). However I’m going to give it a try without using ip2long() at all.

UPDATE: 10000 iterations take about 0.1420 seconds (with valid IP = passing all checks)

In my opinion this is a very clearly structured function which really allows only valid IPs. It is fast too.

OK, Geert… I will try it with ip2long again… I think this one can be good… simple

checking IP 10.0.0.5

valid_ip_geert: 10000 iterations take about 0.1957 seconds

NEW valid_ip: 10000 iterations take about 0.0737 seconds

checking IP 10.0.0

valid_ip_geert: 10000 iterations take about 0.0785 seconds

NEW valid_ip: 10000 iterations take about 0.0706 seconds

checking IP 10.0.0.524

valid_ip_geert: 10000 iterations take about 0.2024 seconds

NEW valid_ip: 10000 iterations take about 0.0688 seconds

The contributors in here deserve their own special release: CI, the Fast version. You’re going to need a lightning flash for a logo instead of a flame.

But Seppo, using only ip2long and long2ip you will return a non-boolean value (which is not what validation expects) and partial IPs will be considered valid.  While in many networking style scripts converting a partial IP to an actual IP is probably a good thing, in validating whether a presented value is a valid IP I would think that is not a good thing.

Seppo - 05 May 2007 05:40 AM

OK, Geert… I will try it with ip2long again… I think this one can be good… simple

function valid_ip_seppo($ip) {
    return $ip == long2ip(ip2long($ip));
}

Your function is faster but is it accurate?