Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109820 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 11581 invoked from network); 23 Apr 2020 18:27:25 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Apr 2020 18:27:25 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 87A8A180546 for ; Thu, 23 Apr 2020 09:59:22 -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=-0.7 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS 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-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 23 Apr 2020 09:59:21 -0700 (PDT) Received: by mail-ot1-f48.google.com with SMTP id i27so7270656ota.7 for ; Thu, 23 Apr 2020 09:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Au8gLxS0D6UkbjaHxquZf0ZCvB1MchlinzSECxj8wks=; b=QOZK4rgXFqtPn96FxopLq8LiGkDbpI/AyqjcNJG5rH9GIkaSb5IG+DaeTl9P1GEa/A WIHXoGzx7RWBehIBWtfPdBuW2FnA3fL9f7HSaWJEALZJAzL22gKs4miIqRXqCIHFkqzA WDrWxuhWyCtdMCdqjzi80JoHd01Y2YCrlA840GgaMIb2+JNyHV9atLuRCaefWPrlYMLT ur0Udg3EHMRkENmzBexiL1G8xGsCxLiTG3hKzfculu/pP40eYOLfQTlWQr+CgIOJRInd FzKgOxSTM8xA1huVvkTABXmpoc5LzfMwx/lK7bI4jbBRnPvTO1XGn8OjVkwHNxe+zk3M PFfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Au8gLxS0D6UkbjaHxquZf0ZCvB1MchlinzSECxj8wks=; b=jVy2ilDNrZhR5OvnYSt/SBiM88TQ+TS3QMQXeoiLDTw9oIT7W1OQRqdz0qHz5XoVRZ N71IAL630WGyfA5uGiXqJRv2c3b6mFM2gbfWNEnrYa9REdZAb37n+XL+KGPdbb5357YT kxxWEa0DY3T78CCY3c8reJdYaNcziM3Oecac6LUl3E3V7ZN/A95aUt8SPkQRlRaQKhVs 5i9HfJwxy2YITE3dxB7OTt/9BaQQvg8Uj9R7NDionIr2nYphyEsMKWjVo9po3p/WpxLm r39ctIcVxCRpHuJIQ/rHPH7H8XBI+PcZssPwwNJfgU4mPtMmWuja/XDKb0llQ+LQesKD 0xvQ== X-Gm-Message-State: AGi0PuYFIYAGkA05+BurAMCc+fnopRRXWaYSKrM0xouQVuSH8EIGE+kS A5pm9gCevIjCzWEzIIuRR4y/TbJOYRWjGiVx4iznhj2/ZuA= X-Google-Smtp-Source: APiQypJCOIxkCK5AqZ5xf2jjr4zWtOdCYhfRkZtIRxC/dNMTl8ZLWGrjXs85RvCyDysH1fgbz1AvfV66dcIaDcJ87kU= X-Received: by 2002:a9d:19ca:: with SMTP id k68mr4377424otk.232.1587661159417; Thu, 23 Apr 2020 09:59:19 -0700 (PDT) MIME-Version: 1.0 Date: Thu, 23 Apr 2020 18:59:07 +0200 Message-ID: To: PHP Internals List Content-Type: multipart/alternative; boundary="0000000000006e4c4c05a3f82bce" Subject: Resolve fallback-to-root-namespace in preloaded implementations From: nicolas.grekas@gmail.com (Nicolas Grekas) --0000000000006e4c4c05a3f82bce Content-Type: text/plain; charset="UTF-8" Hello, with preloading and Composer, we don't need anymore to consider autoloading for functions and/or constants. The reason is that basically Composer is already doing a great job at loading functions: just give it a list of files and it will ensure they are included all the time. Actually, Composer is just an example, all similar "require all the time" strategies work. The drawback of this approach used to be that requiring a bunch of (potentially unused) files could be costly. But now that we have preloading, this cost is zero. As such, autoloading functions/constants would serve no purpose. Then, we periodically have discussions about the rules for namespace resolution of functions/constants. The fallback-to-root-namespace has no measurable performance overhead - the cache is very effective. Yet, Nikita has stated a few times that knowing the type of the arguments of the function being called helps the engine a bit. With JIT, this might be (/become) more important (is that correct, Dmitry and/or Nikita?) I'm thus wondering: could we resolve the fallback-to-root-namespace rule at preload time, for all preloaded implementations? For runtime-loaded code, we would keep the current behavior. In practice, this means that during development (when preloading is not used), we would preserve all the hackability that the rule provides (PHP being a hackable engine is a big PRO, here, this can help e.g. testing a lot). The fallback-to-root-namespace is a wise pragmatic rule that serves the language well IMHO. But in prod, in full-perf mode (aka when preloading is enabled), this proposal would pave the way for better performance with JIT, if confirmed. WDYT? Nicolas PS: I fear I would be unable to implement anything related to this proposal so I'm just sharing the idea to see if it could be interesting. --0000000000006e4c4c05a3f82bce--