Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94898 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 74069 invoked from network); 7 Aug 2016 12:07:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Aug 2016 12:07:50 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@mindplay.dk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@mindplay.dk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.217.173 cause and error) X-PHP-List-Original-Sender: rasmus@mindplay.dk X-Host-Fingerprint: 209.85.217.173 mail-ua0-f173.google.com Received: from [209.85.217.173] ([209.85.217.173:33989] helo=mail-ua0-f173.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 78/61-33134-39427A75 for ; Sun, 07 Aug 2016 08:07:48 -0400 Received: by mail-ua0-f173.google.com with SMTP id 35so227299617uap.1 for ; Sun, 07 Aug 2016 05:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mindplay-dk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZRwo5U40EE3Rb/c8f3NIWtl7oMbDkAd20NavKOAE6S4=; b=VWTKXCYVt+rIOcVqJFA3PtRbLWSQ6jyA5xXbTd/1dODEEaopLiyezt43hn8FGVQxbd 2EHs0D3qwuM1FS2kcnCa8NJEnXoYyKDnVPq/Ho+U4AU410H8piMdF5QOw9XogwEAHGsj A2SzQvRClmiU/Hm5g9Nd9EbySO1WU2rAV/qnioyjHhIqqdNirzHVdkLcLdXQ8lEMXNHA IqoW5NkaYHJZ84hxA29rI8oQMYX9co9mL5RzY23dhL7QVNJ57RFBpycIcVHBVGiAlU32 NKziUbdmCTi+YrIO4WW4zRhnsgwg71/wKuWshu3fXEK1CRiGQ7kyLH9HZ3njzUjdrTgP /OPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZRwo5U40EE3Rb/c8f3NIWtl7oMbDkAd20NavKOAE6S4=; b=kGjXczE8SzERxre/6b59L2N2V+t4MVNk4xgW/BngodoySXRKOU+xiXI6A0H4oeqYDT GPK+3Us4z5jSz3qcWpls0AMh4+RhBfzpvQlV7Yai4XURmPsTPRjkjleyS2WO93bejrk5 mSu9SyjesAJSzfjxagbJ8n7SUnhaJWsgXfBNvjCxbaC3QLJOqqhobbt8vc/ZRmwO+oc4 4S88k4kBzNazlDW1MxG1moch44PK+PpkQe+8kloc72kL1hv9z6I5qZA+zJlQf0nZhR3S /sxy6C1ufiKRVoRhO1ociWRK+G/GVecD3hUzc2yhEx03LdhcPN/GdCg3mY/DVZX/oOhR whpQ== X-Gm-Message-State: AEkoouuEo7G12ijkwWy1yh8cStwR0jmIVpbbhUjqHagS9YtL7wuST3cJOZdDoYgjX2GRn//Hj2sVCOnqOqXlvA== X-Received: by 10.176.82.58 with SMTP id i55mr15278245uaa.103.1470571664227; Sun, 07 Aug 2016 05:07:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.153.195 with HTTP; Sun, 7 Aug 2016 05:07:41 -0700 (PDT) In-Reply-To: References: Date: Sun, 7 Aug 2016 14:07:41 +0200 Message-ID: To: Nikita Popov Cc: PHP internals Content-Type: multipart/alternative; boundary=94eb2c18f6d2a9d32c05397a2584 Subject: Re: [PHP-DEV] Function auto-loading From: rasmus@mindplay.dk (Rasmus Schultz) --94eb2c18f6d2a9d32c05397a2584 Content-Type: text/plain; charset=UTF-8 Of course calling e.g. strpos() should not trigger the auto-loader repeatedly - can we cache the information that the auto-loader was attempted once during the current script execution? so that e.g. only the first call to strpos() triggers the auto-loader? I suppose it would still happen once for every namespace from which strpos() gets called, so maybe this optimization doesn't help much. I guess I'd say, benchmark it before making assumptions? Maybe the performance hit turns out to be negligible in practice. Hard to say. If a performance hit is inevitable, but marginal, I hope that we do not let micro-benchmarks stand in the way of improving the language? With PHP 7, the language is in many ways almost twice as fast as it was before. I think it's fair to say, PHP has problems that are much bigger than performance - to most developers, performance is not a pain point anymore, if it was before PHP 7. I wish that I could change your focus from performance concerns to actually focusing on the language itself. It seems that me that recent performance improvements have become somewhat of a bottleneck that *prevents* new features and (worse) missing features from completing and improving the language? The performance improvements could just as well be viewed as a factor that creates new elbow room for new features and language improvements, which, long term, likely have much more value to more developers than the performance of micro-benchmarks. At the end of the day, for like 9 our of 10 projects, PHP's core performance is not the bottleneck - things like database queries are. The cost of developing a project is also generally unrelated to core performance of the language. Hardware gets cheaper and faster every day. So who or what are we optimizing for? I don't mean to get too side-tracked from the original conversation here, but we should be designing for developers - not for machines. The language is more than fast enough for what most developers need it for - and still nowhere near fast enough for, say, a JSON or XML parser, the kind of things that require C or assembly level performance, and I really don't believe there's a substantial segment of use-cases that fall in between - for most things, either you need performance that PHP can't get near, or you need language features and convenience that low-level languages can't deliver. We're not competing with C - and if we're competing with other scripting languages on performance, we're already in a pretty good position, and people who select a scripting language aren't basing their choice on raw performance in the first place; if that was their concern, they'd pick C. We should focus on competing with other scripting languages on features, convenience, productivity, etc. - if our main concern is competing on low-level concerns like performance, those concerns will override the points that really matter to developers who choose a high-level scripting language, and we will lose. On Sun, Aug 7, 2016 at 1:29 PM, Nikita Popov wrote: > On Sun, Aug 7, 2016 at 1:19 PM, Rasmus Schultz wrote: > >> I'd really like to see the function auto-loading proposal revived and/or >> possibly simplified. >> >> The fact that functions are hard (in some cases impossible) to reach by >> manually issuing require/include statements is, in my opinion, half the >> difficulty, and a much more deeply rooted language problem exacerbating >> what should be trivial problems - e.g. install a Composer package, import >> (use) and call the functions. >> >> Looks like a fair amount of work and discussion was done in 2013 on this >> RFC: >> >> https://wiki.php.net/rfc/function_autoloading >> >> There was a (now stale) proof of concept implementation for the parent RFC >> as well: >> >> https://wiki.php.net/rfc/function_autoloading2 >> >> What happened? >> >> It looks like the discussion stalled mostly over some concerns, including >> reservations about performance, which were already disproved? >> >> One issue apparently was left unaddressed, that of whether a call to an >> undefined function should generate an auto-load call to a namespaced or >> global function - I think this would not be difficult to address: trigger >> auto-loading of the namespaced function first, check if it was loaded, and >> if not, trigger auto-loading of the global function. > > > I feel like the problem here did not get across properly. Calling the > autoloader if a global function with the name exists will totally kill > performance. This means that every call to strpos() or any of the other > functions in the PHP standard library will have to go through the > autoloader first, unless people use fully qualified names (which, > currently, they don't). This is completely out of the question. > > (The case where neither the namespaced nor the global function exists is > not the problem. In that case calling the autoloader for the namespaced and > non-namespaced names in sequence is of course unproblematic.) > > Nikita > > >> Most likely a PSR >> along with Composer auto-loading features will favor a best practice of >> shipping packages with namespaced functions only, so the performance >> implications of checking twice would be negligible in practice. >> >> Being basically unable to ship or consume purely functional packages >> leaves >> the functional side of the language largely an unused historical artifact, >> which is sad. Keeping things functional and stateless often lead to more >> predictable and obvious code - I think the absence of good support for >> functions encourages a lot of over-engineering, e.g. developers >> automatically making everything a class, not as a design choice, for the >> sole reason of being able to ship and reuse what should be simple >> functions. >> >> This RFC looks pretty solid to me. >> >> What will it take to get this rolling again? >> > > --94eb2c18f6d2a9d32c05397a2584--