Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119947 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 87163 invoked from network); 12 Apr 2023 08:24:25 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 12 Apr 2023 08:24:25 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 21A031804DF for ; Wed, 12 Apr 2023 01:24:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 12 Apr 2023 01:24:23 -0700 (PDT) Received: by mail-wr1-f50.google.com with SMTP id v27so796466wra.13 for ; Wed, 12 Apr 2023 01:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681287862; x=1683879862; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fagMpCVClNFkBVwroKeUee0Rho74zqj2aSkmybqY6NQ=; b=TgLsOYX/lr98KgSS35DPgR/6by89IC8hwsytvrGjbKS7ErPgJDycZl0bliF6MD05AU Ad57t45fwyFD8X+TZSjrbTPlGS2FetDCYxKBfEpm0sopTOK3pe+oANiwKT2CcQWCOuWD kgbzH+U1dnfYXDpaxt3+Urw/O+629vY6iXMi4pEAxKWqG/ZMxWfCc3jvdTN9mhxJEeQv S7KpLLVTiLN3rxuwAMg5U5pE96Q514ymY5DlktWJ8Haub1rYVgPFs1IffMhSOfsXFFs8 TCuvLdvdFwwEp6pp3iusW94N3kLpCPUvvtND0PeKloPgRUjmq0ZDRn/wWgtomR1TBci/ BqNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681287862; x=1683879862; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fagMpCVClNFkBVwroKeUee0Rho74zqj2aSkmybqY6NQ=; b=uKiyOBqwyc6lFTf40OwfqwQwtZFyMhlmxzTDh8WPOIV0oBXq4M86jgI5YqPASVvBXC NIc+dmicKZe34sqwp5c78Yk0bzBCY5nLgidvFjZglHMLFNXl432a19Rram6+gwSmBBwr FTgw4cLfGmHAal+MMDJoYVBHkifNCMINW7du6S9oJQ9PQZ+/Gceh7wPIC2ITlmx4yo1W MN6hN8Bfp8KY+x2Qk2MBiO0WxaXdHsxpR6wnddNb+8aBo04N+7KAEB1Vc3GjQGEfNesa Nbk2yOsKmuOz1UrujeiMu5iHKs3rmRqFE6LkNltbwhSvnOaHsz124j8z9OtK2JjIfXSi x10A== X-Gm-Message-State: AAQBX9df1GMPebRr0384nK4+wRy7Sf7UfvWTVhRo2lfRbmv6MBeqOyfU rT2DMUtuSPT63T4idaqX942KWQWBVRr16sKc6E8= X-Google-Smtp-Source: AKy350ZHodRbIZxGnJM/uUl7vLKU1ZmCUxGNAxgM3RlXL/UueGrD1EcZyp03cqwChdj8lXtwGRgtjLhiEf+QZL+ppjk= X-Received: by 2002:adf:db04:0:b0:2f2:e730:503c with SMTP id s4-20020adfdb04000000b002f2e730503cmr1159021wri.5.1681287861948; Wed, 12 Apr 2023 01:24:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 12 Apr 2023 10:24:10 +0200 Message-ID: To: "G. P. B." Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000c6d36a05f91f5592" Subject: Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --000000000000c6d36a05f91f5592 Content-Type: text/plain; charset="UTF-8" Hello George, Dan and I would like to propose a new core autoloading mechanism that fixes > some minor design issues with the current class autoloading mechanism and > introduce a brand-new function autoloading mechanism: > https://wiki.php.net/rfc/core-autoloading > > The existing SPL autoloading functions would become aliases to the new Core > ones and will continue to work without any migrations needing to be > performed. > Thanks to you and Dan for the RFC. I have two main questions about this: 1. What's the performance hit? 2. If the perf hit is measurable, is function autoloading worth it? aka what problem does it address? About the perf hit, I see that you put a lot of thought into minimizing it and that's sound. The way I see this feature be spread to userland is via composer of course. I foresee that composer will add a way for packages to declare function autoloading. This means that every application that uses composer will be impacted by the perf overhead eventually (aka the case of "programs that do not have a function autoloader registered" mentioned in the RFC won't happen in practice.) In e.g. https://github.com/php/php-src/pull/6627#issuecomment-773922448, Dmitry explains that adding inheritance cache to PHP provided a 8% perf benefit when running a demo app. I would like to see a similar benchmark with function autoloading enabled. https://github.com/phpbenchmarks/ provides several demo apps so it could be a nice playground for running this. Then, depending on the resulting numbers, I anticipate several possible outcomes: - if the impact is really low, then all is fine and we can keep things as is; - otherwise, I'm also interested in this idea to scope function autoloading per namespace, so that the engine can filter ahead of calling any userland autoloaders; - if the overhead is still significant, could another idea be to load functions per namespace, where the engine would ensure to call function autoloaders only once per namespace? Even with the current proposal, I can easily anticipate that a common practice for package authors could be to put all functions in one file, and register a function autoloader that would require that file for any of the functions in it. Loading per namespace would fit this loading strategy. But before exploring this idea, let's get some numbers about the performance of the previous approaches. Then comes my second main question: what does this solve? To me, class autoloading is a performance feature. If we didn't care about performance, we would be fine with eagerly loading a bunch of classes as e.g. Java does. But because we run PHP mainly in short-lived request/response loops, loading just the few classes we need to serve a specific request provides the best performance. In recent versions of PHP, we may question this practice, since we now have a crazy good opcache. Of course, I'm not suggesting removing autoloading for classes. But if we do have that crazy good opcache, what do we need function autoloading for? The current way for package authors to declare classes is via composer "files " entry. One could argue in the past that this adds needless "require" on the hotpath. But if they cost nothing thanks to recent opcache improvements, we don't need to care, do we? At least, we need to compare both approaches, because if the main argument for adding function autoloading is lazy-loading of function implementations, then it must be faster than eager-loading. This circles back to my previous question, so we'd really need a thorough perf analysis IMHO. Nicolas --000000000000c6d36a05f91f5592--