isset（）vs strlen（） - 快速/清除字符串长度计算 [英] isset() vs strlen() - a fast/clear string length calculation

问题描述

我遇到了这段代码...

I came across this code...

if(isset($string[255])) {
    // too long
}

/ p>

isset() is between 6 and 40 faster than

if(strlen($string) > 255) {
    // too long
}

isset（）的唯一缺点是代码不清楚 - 我们不能马上知道完成（见pekka的答案）。我们可以在一个函数中包装isset（），即strlt（$ string，255），但是我们放松了isset（）的速度优点。

The only drawback to the isset() is that the code is unclear - we cannot tell right away what is being done (see pekka's answer). We can wrap isset() within a function i.e. strlt($string,255) but we then loose the speed benefits of isset().

在保持代码可读性的同时使用更快的isset（）函数？

编辑：测试显示速度 http://codepad.org/ztYF0bE3

strlen() over 1000000 iterations 7.5193998813629
isset() over 1000000 iterations 0.29940009117126

EDIT2：这里是为什么isset / p>

EDIT2 : here's why isset() is faster

$string = 'abcdefg';
var_dump($string[2]);
Output: string(1) "c"

$string = 'abcdefg';
if (isset($string[7])){
     echo $string[7].' found!';
  }else{
     echo 'No character found at position 7!';
}

这比使用strlen（）更快，因为...调用函数比使用语言构造更昂贵。 http://www.phpreferencebook.com/tips/ use-isset-instead-of-strlen /

This is faster than using strlen() because, "… calling a function is more expensive than using a language construct." http://www.phpreferencebook.com/tips/use-isset-instead-of-strlen/

EDIT3：我总是被教导对mirco优化感兴趣。可能是因为我在一个时间教授计算机上的资源很小。我对这个想法感到开放，这可能不重要，在答案中有一些很好的论据反对它。
我开始了一个新的问题探索这个... 是微优化重要的是编码？

EDIT3 : I was always taught to be interested in mirco-optimisation. Probably because I was taught at a time when resources on computers were tiny. I'm open to the idea that it may not be important, there are some good arguments against it in the answers. I've started a new question exploring this... Is micro-optimisation important when coding?

推荐答案

OK所以我运行测试，因为我几乎不相信isset是更快，但是它是，并且相当多。 isset（）方法的速度一般大约快6倍。

OK so I ran the tests since I could hardly believe that the isset() method is faster, but yes it is, and considerably so. The isset() method is consistently about 6 times faster.

我尝试过各种大小的字符串，运行不同数量的迭代;比率保持不变，以及总运行长度（对于不同大小的字符串），因为isset（）和strlen（）都是O（1）（这是有意义的 - isset只需要做一次查找一个C数组和strlen（）只返回为字符串保存的大小计数）。

I have tried with strings of various sizes and running a varying amount of iterations; the ratios remain the same, and also the total running length by the way (for strings of varying sizes), because both isset() and strlen() are O(1) (which makes sense - isset only needs to do a lookup in a C array, and strlen() only returns the size count that is kept for the string).

我在php源中查找，我认为我粗略了解原因。 isset（），因为它不是一个函数，而是一个语言结构，在Zend VM中有自己的操作码。因此，它不需要在函数表中查找，并且它可以进行更专门的参数解析。代码在zend_builtin_functions.c中用于strlen（）和zend_compile.c用于isset（），对于那些感兴趣的用户。

I looked it up in the php source, and I think I roughly understand why. isset(), because it is not a function but a language construct, has its own opcode in the Zend VM. Therefore, it doesn't need to be looked up in the function table and it can do more specialized parameter parsing. Code is in zend_builtin_functions.c for strlen() and zend_compile.c for isset(), for those interested.

从技术角度看，有关isset（）方法的任何问题;但是对于那些不习惯成语的人来说，它更难读。此外，isset（）方法将在时间上是恒定的，而当改变构建到PHP中的函数的数量时，strlen（）方法将是O（n）。意思是，如果你编译PHP和静态编译在许多函数，所有的函数调用（包括strlen（））将会更慢;但isset（）将是常量。然而，这种差异实际上可以忽略不计;我也不知道有多少函数指针表被维护，所以如果用户定义的函数也有影响。我似乎记得他们在不同的表，因此是不相关的这种情况下，但它是一段时间，因为我上次真正使用这个。

To tie this back to the original question, I don't see any issues with the isset() method from a technical point of view; but imo it is harder to read for people who are not used to the idiom. Futhermore, the isset() method will be constant in time, while the strlen() method will be O(n) when varying the amount of functions that are build into PHP. Meaning, if you build PHP and statically compile in many functions, all function calls (including strlen()) will be slower; but isset() will be constant. However this difference will in practice be negligible; I also don't know how many function pointer tables are maintained, so if user-defined functions also have an influence. I seem to remember they are in a different table and therefore are irrelevant for this case, but it's been a while since I last really worked with this.

对于其余的没有看到任何缺点的isset（）方法。我不知道其他方法来获取字符串的长度，当不考虑有目的的复杂的例如爆炸+计数和这样的事情。

For the rest I don't see any drawbacks to the isset() method. I don't know of other ways to get the length of a string, when not considering purposefully convoluted ones like explode+count and things like that.

最后，我也测试你的建议上面的包装isset（）到一个函数。这比甚至strlen（）方法慢，因为你需要另一个函数调用，因此另一个哈希表查找。额外参数（用于检查的大小）的开销是可忽略的;作为不通过引用传递的字符串的复制。

Finally, I also tested your suggestion above of wrapping isset() into a function. This is slower than even the strlen() method because you need another function call, and therefore another hash table lookup. The overhead of the extra parameter (for the size to check against) is negligible; as is the copying of the string when not passed by reference.

这篇关于isset（）vs strlen（） - 快速/清除字符串长度计算的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！