Performance: drupal_substr

script used for testing

put in drupal directory and run with "php speed.php"

That iconv implementation might be returning the wrong substring if the UTF32 output contains a byte order mark. But the performance characteristic would be roughly the same after it was fixed.

There's some promising-looking LGPL code here.

This may also be a good thing to incorporate if it turns out to be true:

 111  /**
 112   * Unicode aware replacement for strlen()
 113   *
 114   * utf8_decode() converts characters that are not in ISO-8859-1
 115   * to '?', which, for the purpose of counting, is alright - It's
 116   * even faster than mb_strlen.
 117   *
 118   * @author <chernyshevsky at hotmail dot com>
 119   * @see    strlen()
 120   * @see    utf8_decode()
 121   */
 122  function utf8_strlen($string){
 123    return strlen(utf8_decode($string));
 124  }

Uploading a new test script which:

1. fixes the bug where outer-loop $i was getting clobbered by inner-loop $i. Oops.
2. tests the splitbrain.org utf8_substr
3. uses a longer test string. this causes the current drupal_substr to really croak.

Khalid,

I don't know. I believe I noticed the problem while calling drupal_substr() from my own code.

> Are there some performance suggestions here?
Nancy, I went back and took a look at what I did -- I ended up not using drupal_substr() but instead doing an iconv(substr(iconv())) like the one in the test file attached here: http://drupal.org/files/issues/speed.php__0.txt

Or you could try and replace drupal_substr() wholesale, with either the iconv() version or the utf8_substr() that's also in the above file.

Khalid, the question is not with a particular Drupal core menu callback being slow, it's whether or not drupal_substr() is fast enough to be a generally useful public Drupal API function for contrib modules to use.