PHP函数调用的重要性有多大?

时间:2013-07-31 13:35:50

标签: php optimization php-5.2

我对PHP比较陌生,慢慢学习特定于语言的特性。有一件事我得到了很大的好处,那就是我(所以我被告知)使用了太多的函数调用,并且我被要求做一些事情来解决它们。这是两个例子:

// Change this:
} catch (Exception $e) {
  print "It seems that error " . $e->getCode() . " occured";
  log("Error: " . $e->getCode());
}

// To this:
} catch (Exception $e) {
  $code = $e->getCode();
  print "It seems that error " . $code . " occured";
  log("Error: " . $code);
}

第二个例子

// Change this:
$customer->setProducts($products);

// To this:
if (!empty($products)) {
  $customer->setProducts($products);
}

在第一个示例中,我发现将$e->getCode()广告分配给$code广告会产生轻微的认知开销; “什么是'$ code'?啊,这是异常的代码。”而第二个例子增加了圈复杂度。在这两个例子中,我发现优化是以可读性和可维护性为代价的。

性能提升是否值得,还是微观优化?

我应该注意到,我们现在仍然坚持使用PHP 5.2。

我做了一些非常粗略的基准测试,发现功能调用性能命中率在10%到70%之间,具体取决于我的工作台测试的性质。我承认这很重要。但在该catch块被击中之前,有一个数据库和HTTP端点的调用。在$products上设置$customer之前,$products数组发生了一个复杂的排序。 在一天结束时,这种优化是否证明了使代码更难以阅读和维护的成本?或者,尽管这些示例是简化的,但是有人发现第二个示例同样简单易读比第一个(我是一个维纳)?

任何人都可以引用任何有关此事的好文章或研究吗?

编辑:

示例台架测试:

<?php
class Foo {
        private $list;
        public function setList($list) {
                $this->list = $list;
        }
}

$foo1 = new Foo();

for($i = 0; $i < 1000000; $i++) {
        $a = array();
        if (!empty($a))
                $foo1->setList($a);
}
?>

使用time命令运行该文件。在一台特定的机器上,经过几次运行后平均需要0.60秒。注释掉if (!empty($a))会导致它平均需要3.00秒才能运行。

澄清:这些都是示例。第一个示例演示了可怕的异常处理和可能的DRY违规,但代价是一个简单的,非特定于域的示例。

4 个答案:

答案 0 :(得分:6)

PHP函数调用开销恰好是15.5355%。

:)只是搅拌锅。

说真的,这里有几个很棒的链接:

Is it possible to have too many functions in a PHP application?

functions vs repeated code

这些链接上的代码可维护性与速度讨论解决了OP所暗示的(可能更重要的)问题,但只是添加了一些可能相关的小数据,并希望将来遇到这个问题的人有用,以下是在2011 Macbook Pro上运行以下代码的结果(驱动器空间非常小,运行的程序太多)。

如其他地方所述,在决定是否调用函数或将代码“内联”时,一个重要的考虑因素是在某个代码块中调用函数的次数。函数被调用的次数越多,就越需要考虑在线工作。

结果(以秒为单位的时间)

呼叫功能方法|在线方法|差异|百分比

1,000次迭代(4次运行)

0.0039088726043701 | 0.0031478404998779 | 0.00076103210449219 | 19.4694

0.0038208961486816 | 0.0025999546051025 | 0.0012209415435791 | 31.9543

0.0030159950256348 | 0.0029480457305908 | 6.7949295043945E-5 | 2.2530

0.0031449794769287 | 0.0031390190124512 | 5.9604644775391E-6 | 0.1895

1,000,000次迭代(4次运行)

3.1843111515045 | 2.6896121501923 | 0.49469900131226 | 15.5355

3.131945848465 | 2.7114839553833 | 0.42046189308167 | 13.4249

3.0256152153015 | 2.7648048400879 | 0.26081037521362 | 8.6201

3.1251409053802 | 2.7397727966309 | 0.38536810874939 | 12.3312

function postgres_friendly_number($dirtyString) {

    $cleanString = str_ireplace("(", "-", $dirtyString);
    $badChars = array("$", ",", ")");
    $cleanString = str_ireplace($badChars, "", $cleanString);

    return $cleanString;

}


//main
$badNumberString = '-$590,832.61';

$iterations = 1000000;

$startTime = microtime(true);
for ($i = 1; $i <= $iterations; $i++) {
    $goodNumberString = postgres_friendly_number($badNumberString);
}
$endTime = microtime(true);
$firstTime = ($endTime - $startTime); 

$startTime = microtime(true);
for ($i = 1; $i <= $iterations; $i++) {
    $goodNumberString = str_ireplace("(", "-", $badNumberString);
    $badChars = array("$", ",", ")");
    $goodNumberString = str_ireplace($badChars, "", $goodNumberString);
}
$endTime = microtime(true); 
$secondTime = ($endTime - $startTime); 

$timeDifference = $firstTime - $secondTime;
$percentDifference = (( $timeDifference / $firstTime ) * 100);

答案 1 :(得分:6)

还没有人讨论过服务器硬件与函数调用开销的关系。

调用函数时,所有CPU的寄存器都包含与当前执行点相关的数据。所有CPU的寄存器必须保存到内存中(通常是进程的堆栈),或者没有希望永远返回到该执行点并继续执行。从函数返回时,必须从内存中恢复所有CPU的寄存器(通常是进程的堆栈)。

因此,可以看到一串嵌套函数调用如何为进程增加开销。 CPU的寄存器必须一遍又一遍地保存在堆栈中,并反复恢复以从函数中恢复。

这实际上是函数调用开销的来源。如果传递了函数参数,那么在调用函数之前必须重复这些参数。因此,将大型数组作为函数参数传递是一种糟糕的设计。

在使用getter / setter的开销上已经对面向对象的PHP进行了研究。删除所有getter / setter会将执行时间缩短约50%。而这仅仅是由于函数调用开销。

答案 2 :(得分:4)

规范的PHP实现非常慢,因为它易于实现,PHP的目标应用不需要快速函数调用等原始性能。

您可能需要考虑其他PHP implementations

如果您正在编写应该用PHP编写的应用程序(通过网络将数据从数据库转储到浏览器),那么函数调用开销并不重要。当然不要忘记重复代码,因为你害怕使用函数会产生过多的开销。

答案 3 :(得分:3)

我对你的术语感到困惑。一般是函数调用开销 表示从函数调用返回所涉及的开销。 而不是内联处理。它不是函数调用的总成本。 它只是准备参数和返回值以及进行分支的成本。

你遇到的问题是PHP和其他弱类型的脚本风格语言在确定函数是否有副作用方面非常糟糕。因此,不是将函数的结果存储为临时值,而是进行多次调用。如果函数正在做一些复杂的事情,这将是非常低效的。

所以,底线是:调用函数一次并存储并重用结果! 不要使用相同的参数多次调用相同的函数。 (没有充分理由)