On Sun, 2024-08-04 at 19:53 +0200, Ilija Tovilo wrote: > Hi Claude > > On Fri, Aug 2, 2024 at 9:02 PM Claude Pache <claude.pa...@gmail.com> > wrote: > > > > I propose the following alternative approach: > > > > * establish a restricted whitelist of global functions for which > > the performance gain would be noteworthy if there wasn’t any need > > to look at local scope first; > > > > * for those functions, disallow to define a function of same name > > in any namespace, e.g.: https://3v4l.org/RKnZt > > > > That way, those functions could be optimised, but the current > > semantics of namespace lookup would remain unchanged. > > That would be an improvement over the status quo. However, if you > look > at the bullet points in my original email, while some of the > optimizations apply only to some functions (CTE, custom opcodes and > frameless calls), others apply to all internal, global functions > (double-lookup, lookup by offset, specialized argument passing). > Hence, we may only get a fraction of the benefits by restricting the > optimization to a handful of functions. I also wonder if the impact > is > actually bigger, as then there's no workaround for redeclaring the > function, requiring much bigger refactoring. > > Ilija
Also, overriding any default function is one of the benefits of name spacing in the first place. If we say, "built-in functions can't be overridden, then you are basically saying that all built-in functions are global. But there is a valid use case for overriding built-ins. You may want to disable built-in functionality with a stub for unit testing. There should probably be a per-file way of setting the default either way without ns lookups. use global functions - or - use local functions - or - omit directive to use dynamic NS lookup for BC.
