Hey Tim On 10/04/2023 14:45, Tim Düsterhus wrote: > Hi > > On 4/8/23 22:17, Niels Dossche wrote: >> I think this could be made more generic, and be cleaned up. >> But I don't know if something like this is desired in PHP. > > Yes, please. I believe that “performance” should not influence API design if > it can be avoided. Instead the heavy lifting of optimization should be done > by the engine (see also: https://externals.io/message/118896#118921). >
I agree. > The suggested optimization of "the input is overwritten with the output" > would then also allow to avoid introducing reference parameters just for > optimization purposes. The sort() family comes to my mind and also the > shuffle() function. Randomizer::shuffleArray() already returns a copy and > thus would benefit from the proposed optimization for $a = > $r->shuffleArray($a). > I did extend my optimization since the first time I posted it here. It can handle two cases: - $x = array_something($x, ...) like I previously showed with array_merge - $x = array_something(temporary_array_with_refcount_1,...) which is new There is one caveat with the first optimization: it is only safe if we know for sure no exception can happen during array modification. Because, if an exception happens during modification, then the changed array is already visible to the exception handler, but this isn't allowed because the assignment didn't happen yet. This "exception problem" does not happen for the second optimization though. So I looked if it was possible to do the optimization for shuffleArray. It is only possible for the second case, because I see some EG(exception) checks inside php_array_data_shuffle(). Unless we can determine upfront which random algorithms have an exception-free range function. > Best regards > Tim Düsterhus Kind regards Niels -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
