confirm this change. this is due to the 5.4 performance improvement: "literal 
cache"

@dmitry, maybe we should not cache the function entry for INIT_NS_FCALL?

thanks

or maybe we should document this behavior, since disable it will bring performance 
issue

@gen the main brief is, when you first call to \Foo\Bar,  the 'time' constant in 
the \Foo\Bar function, will bundle to "time function", in the first time , it 
obviously will be bundled to \time.

then when you sencond call to it. PHP will use that cache instead of look up in 
function table again for "time" function, to increase performance..

so, if we disable the cache, then performance slowdown...

what do you think?  a workaround is define a Foo\Bar2, after you eval, you call 
to it, then it will bundled to \Foo\Time..

The main issue I see is that is_callabe() is lying. It says that '\Foo\bar' is callable, but in fact it's not. So just document this behavior is not enough imo, is_callabe should be tweaked to reflect actual status.

And I don't quite understand suggested workaraund. Could you please give a simple example? In my usecase I try to mock time function to avoid sleep() calls:
https://github.com/rybakit/phive-queue/blob/master/tests/Phive/Tests/Queue/AbstractQueueTest.php#L59
https://github.com/rybakit/phive-queue/blob/master/src/Phive/Queue/InMemoryQueue.php#L40

'\Foo\bar' -> '\Foo\time' in my prev comment

I suppose the bug has to be fixed.

The problem that the fix will slowdown each call to unqualified function from a namespace :(

I'm not sure if we like to do it...

Dmitry,

I came across this one myself (see http://3v4l.org/KSIDh) and found this bugrep when I came to report it.

I think that one-time caching as we've started to do with function look-up is an important performance feature, and something that we should look to extend -- though this is a wider discussion than this bugrep, probably a DL list discussion.

I haven't gone through the current implementation yet, but my immediate thought is that this really just a cache-coherence issue in a cache where the invalidation rates are very low, so even if cache flushing was a relatively expensive operation, then the expected (that is average) overhead would still be small.  I want to think about this some more and look at the performance issues around some approaches, before posting further -- Terry

BTW, the title of this bug is misleading.  It can still occur for *any* INCLUDE_OR_EVAL of a namespaced override of a builtin function, eg.

namespace fred;
some_function_which_executes_builtin();
include "some_include_in_namespace_fred_which overrides_same_builtin();
some_function_which_executes_builtin();

Damn, why can't you edit your own comments :-)  The include should read:

include "some_include_in_namespace_fred_which overrides_same_builtin.php";

of course.

The same problem also applies to constants when accessing from a namespaced class - if the first the time the constant is accessed it is defined globally but not in the local namespace, then that global value will be used for all future accesses even if it is later defined in the local namespace.

Since overriding global functions / constants is mostly used just for testing, could this be added as a php.ini option, like 
literal_cache_disable = 1

Would it also be expensive to invalidate specific (not all) keys in the "literal cache" each time a function or a constant is defined?

I'd avoid a global INI setting if possible.

Still present in 7.3.0-beta2: https://3v4l.org/IMmoO