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 <nikita....@gmail.com> wrote: > On Sun, Aug 7, 2016 at 1:19 PM, Rasmus Schultz <ras...@mindplay.dk> 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? >> > >
