Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:68717 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17376 invoked from network); 30 Aug 2013 11:17:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Aug 2013 11:17:05 -0000 Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.181 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.220.181 mail-vc0-f181.google.com Received: from [209.85.220.181] ([209.85.220.181:38296] helo=mail-vc0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9D/C9-64695-F2F70225 for ; Fri, 30 Aug 2013 07:17:03 -0400 Received: by mail-vc0-f181.google.com with SMTP id hz10so1171418vcb.26 for ; Fri, 30 Aug 2013 04:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fWjnTYJdy9lP7mpmR2juxCsGBCjBs/logEnHAtoORFM=; b=BtprebOSdBTTBjaUlSrJJKoMWQKWgKx9Rr55OxPGtc1yVcKc+vw/u/BY0+8y/aJGT7 IR9ZnSncqsARczL6kgMG9qxalnJjNXB6ZbwNmMbXBdI/eUu4oDNeBphtqE/yk1HcKRrr kohur8y/BCABVssNa1bSj8+71Nkaoz3ewg3EvRh24kgGY174Rt+RR2pweegFAQpIlpbk gBesLFUIAgzwEeMhekllz9UmDWjoCIPTYD5dRmnjC8QVtNecfeXWrxHzlXby0pEvf2Pp 739+nk5vr9tRIwNgw9axayWmLdTiq5/NqfupFnWfW1n18eIwA0ViC45yZ0OFEQRhVqhe /sdA== MIME-Version: 1.0 X-Received: by 10.221.47.193 with SMTP id ut1mr7743885vcb.8.1377861419824; Fri, 30 Aug 2013 04:16:59 -0700 (PDT) Received: by 10.58.94.201 with HTTP; Fri, 30 Aug 2013 04:16:59 -0700 (PDT) In-Reply-To: <5220262A.6040702@sugarcrm.com> References: <5220262A.6040702@sugarcrm.com> Date: Fri, 30 Aug 2013 07:16:59 -0400 Message-ID: To: Stas Malyshev Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a113392ec7a7fd704e5285ce5 Subject: Re: [PHP-DEV] [DRAFT] [RFC] Function autoloading From: ircmaxell@gmail.com (Anthony Ferrara) --001a113392ec7a7fd704e5285ce5 Content-Type: text/plain; charset=ISO-8859-1 Stas, Moreover, since this replaces a simple hash lookup with additional two > function calls (and also other operations included in those) everywhere > in the engine, it will also have performance impact of one of the most > frequently used operations in the engine - function calls - while > providing absolutely no benefit for 100% of existing code and 99.99% of > future code. > This was already directly covered in the RFC already: https://wiki.php.net/rfc/function_autoloading#c_api_backwards_compatibility Basically, two new macros are introduced which expand directly to hash lookups. #define ZEND_LOOKUP_FUNCTION_BY_NAME(name, name_length, fbc) (zend_hash_find(EG(function_table), (name), (name_length) + 1, (void**) (fbc)) == SUCCESS || zend_lookup_function((name), (name_length), (fbc)) == SUCCESS) So nothing changes from present (at all) unless a function is not defined. Today, that's an error case. So the only performance change occurs if zend_hash_find (which is already there) returns FAILURE. THEN the logic which includes autoloading would run. So no, there should be no performance impact at all to existing code thanks to operator short circuiting. Anthony --001a113392ec7a7fd704e5285ce5--