1. 程式人生 > >陣列非數字鍵名引號的必要性

陣列非數字鍵名引號的必要性

我看到過很多人運算元組的時候, 對於陣列中的非數字鍵名不使用引號,

  $array[key] = $value;

我可以理解有些人可能會覺得這樣的程式碼很”整潔”, 並且也能正常執行.
更甚至,如果他很”幸運的”php配置的好:

error_reporting = ~E_NOTICE

他也許永遠都沉浸在自己的”整潔”風格中, 看不到任何的NOTICE提示, 也不會意識到, 他這麼做, 能損失多少的效能~

來, 我們一起來看看:

good.php:
<?php
   $array = array();
   $i = 0;
   while(++$i < 1000){
       $array['good'] = 2;
   }
?>

bad.php:
<?php
   $array = array();
   $i = 0;
   while(++$i < 1000){
       $array[good] = 2;
   }
?>

分別看執行時間(多次平均時間):
加引號的:

$ time php -f good.php

real    0m0.013s
user    0m0.005s
sys     0m0.007s

不加引號的:

$ time php -f bad.php

PHP Notice:  Use of undefined constant bad - assumed 'bad' in /home/huixinchen/tmp/bad.php
on line (此處省略999行NOTICE)
real    0m0.100s
user    0m0.020s
sys     0m0.029s

看看,差別有多大?
哦, 或許我們應該模擬一下那些”幸運的”人們的情況, 去掉花費在記錄NOTICE的開銷, 看看~

$ time php -f bad.php

real    0m0.037s
user    0m0.018s
sys     0m0.018s

我們可以看出, 基本上, 使用引號,和不使用引號的效率損失在3倍以上

那麼, 這些效率損失到哪裡去了呢?

我們分別看下, 倆個檔案生成的OPCODE序列:

good.php :

filename:       /home/huixinchen/tmp/good.php
compiled vars:  !0 = $array, !1 = $i
line     #  op                           fetch          ext  return  operands
-------------------------------------------------------------------------------
   2     0  INIT_ARRAY                                       ~0
         1  ASSIGN                                                   !0, ~0
   3     2  ASSIGN                                                   !1, 0
   4     3  PRE_INC                                          $3      !1
         4  IS_SMALLER                                       ~4      $3, 1000
         5  JMPZ                                                     ~4, ->9
   5     6  ZEND_ASSIGN_DIM                                          !0, 'good'
         7  ZEND_OP_DATA                                             2, $6
   6     8  JMP                                                      ->3
   8     9  RETURN                                                   1
        10* ZEND_HANDLE_EXCEPTION

bad.php :

filename:       /home/huixinchen/tmp/bad.php
compiled vars:  !0 = $array, !1 = $i
line     #  op                           fetch          ext  return  operands
-------------------------------------------------------------------------------
   2     0  INIT_ARRAY                                       ~0
         1  ASSIGN                                                   !0, ~0
   3     2  ASSIGN                                                   !1, 0
   4     3  PRE_INC                                          $3      !1
         4  IS_SMALLER                                       ~4      $3, 1000
         5  JMPZ                                                     ~4, ->10
   5     6  FETCH_CONSTANT                                   ~5      'bad'
         7  ZEND_ASSIGN_DIM                                          !0, ~5
         8  ZEND_OP_DATA                                             2, $7
   6     9  JMP                                                      ->3
   8    10  RETURN                                                   1
        11* ZEND_HANDLE_EXCEPTION

我們可以看出(其實,根據NOTICE的提示也知道), PHP會把沒有引號引起來的鍵名當作是常量去獲取, 當找不到的時候, 丟擲一個NOTICE, 然後再根據”常量明”生成一個字串, 然後再講這個字串做為鍵名繼續~

聰明的你一定會想到, 可能會出現如下不可預期的錯誤:

define('key_name' , 'laruence');
....
//省略很多行程式碼
$array[key_name] = 2; //變成了 $array['laruence'] = 2;
//這樣的錯誤, 你會很鬱悶吧?

明白了麼? 陣列中的非數字鍵的鍵名一定要有引號啊~
哦, 還記得有人會說, 那在字串變數替換的時候, 寫引號會導致錯誤,
恩, 標準寫法:

$string = "variable value is {$array['key']}"

我很贊同:”be lazy”, 但是, lazy也是應該有原則的.

最後, 好的程式碼,不應該通過關閉error_reporting來偽裝.

附註, FETCH_CONSTANT OPCODE中找不到常量的相關邏輯:

....
if (!zend_get_constant(opline->op2.u.constant.value.str.val,
     opline->op2.u.constant.value.str.len, &EX_T(opline->result.u.var).tmp_var TSRMLS_CC)) {
       zend_error(E_NOTICE, "Use of undefined constant %s - assumed '%s'",
                opline->op2.u.constant.value.str.val,
                opline->op2.u.constant.value.str.val);
       EX_T(opline->result.u.var).tmp_var = opline->op2.u.constant;//獲取"常量"名字串
       zval_copy_ctor(&EX_T(opline->result.u.var).tmp_var);//分配空間,生成字串
}
....