> De : Pierre Joye [mailto:pierre....@gmail.com] > > > Sorry, I am not sure I understand how the opcode cache, as it exists now, > can understand this. Do you mean that opcode cache code would need to be > modified ? > > Yes and no. Yes if we want them to do not even try to update files > that are statically built in extensions. And yes, if we want that (for > whatever reasons I cannot think about right now).
Sorry, it must be too late :) AFAIR, the opcode cache attempts a stat() call on the filename it receives to get its mtime and use it to determine if file was modified since it was cached. I don't understand how an opcode cache can do a stat() on the filename you provide as, without a stream wrapper, there is no way to access such information (which doesn't even have any sense here). Your filename will be recognized as a plain filename, the libc stat() call will look for this filename in the current directory, it won't be found, and opcode caching will fail. If the file doesn't have an associated stream-wrapped path, you cannot issue a stat() on it and I don't see how it can be cached. Where am I wrong ? > That's PHP7, we can and have already broken BC internally. So, you confirm that opcache is the only supported opcode cache in PHP 7 ? That's a good thing. I know that PHP7 breaks BC, I just wanted to know if developments in this branch had to remain compatible with APC and friends. > As Sara pointed out , persistent opcode would be way better but as far > as I remember it is something very tricky to do (due to how the > address and offset are stored), maybe it changed now for 7, I did not > check that part. I remember we already discussed about PHP userspace code persistence years ago. What I remember most is that it was a nightmare with tons of side effects, but we were including PHP data persistence in the scope, which one more step towards hell. Maybe the core has evolved and things are easier now, especially in PHP7. Anyway, from what I remember, Sara is the best one to design and implement an amazing solution in an amazingly short time (no flattery here :) Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
