> Just to be clear, I think you're referring to "compared to the case of a bare string callable", e.g.: array_filter($arr, 'is_numeric') vs. array_filter($arr, fn($x) => !is_numeric($x));
Yes, because I can optimize it when array_filter() is "positive-only", but I can't when I need to be "negative-only", so I depend on a fn($x) => !is_numeric($x). I not have a php-src enabled for now, but I pretends to have soon so I can try to apply it directly to C and compile it, so for now I am limited to what PHP could do. > "Citation required" still stands in that case, but even if that function call overhead does amount to 70% (and for inlined functions like is_numeric it might), I would say that's not cause to add complexity to the filter function, but rather cause to look at ways to optimize the code that exists in the wild. It should be possible for the engine (at some layer) to look at that closure and see that it's just negating some proxied call and elide setting up the intermediate frame. Microoptimizations SHOULD be the engine's job, not userspace's. I really think that it should be a good solution, but how hard should it be to create a proxy like that? Atenciosamente, David Rodrigues Em seg., 31 de ago. de 2020 às 11:55, Sara Golemon <poll...@php.net> escreveu: > On Mon, Aug 31, 2020 at 9:41 AM David Rodrigues <david.pro...@gmail.com> > wrote: > >> > I agree with Larry that userland implementation is trivial enough that >> it >> > doesn't really need to be implemented in core. It's just syntactic sugar >> > that's probably more trouble than it's worth. That being said, I'm by >> far >> > an expert when it comes to core, so I can't really say 1.) what >> performance >> > benefits it would provide or 2.) how hard (or easy) it would be to >> > implement. >> >> 1. array_reject() should be 70% faster than array_filter(arr, fn() ...) >> version; >> >> > Citation Needed. > > Just to be clear, I think you're referring to "compared to the case of a > bare string callable", e.g.: array_filter($arr, 'is_numeric') vs. > array_filter($arr, fn($x) => !is_numeric($x)); > > "Citation required" still stands in that case, but even if that function > call overhead does amount to 70% (and for inlined functions like is_numeric > it might), I would say that's not cause to add complexity to the filter > function, but rather cause to look at ways to optimize the code that exists > in the wild. It should be possible for the engine (at some layer) to look > at that closure and see that it's just negating some proxied call and elide > setting up the intermediate frame. Microoptimizations SHOULD be the > engine's job, not userspace's. > > -Sara >
