Re: [APC-DEV] 3.0.12 release
| From: | Rasmus Lerdorf | Date: | Sun, 03 Sep 2006 17:43:51 +0000 |
| Subject: | Re: [APC-DEV] 3.0.12 release | ||
| References: | 1 2 | Groups: | php.apc.dev |
| Request: | Send a blank email to php-apc-dev+get-4@lists.php.net to get a copy of this message | ||
Gopal Vijayaraghavan wrote:
Rasmus Lerdorf wrote:Yes, I am not too worried about the optimizer at this point.I am seeing lots of commits fly by from Gopal, Sara and Ilia. Cool! ;)I guess this list is working then ;)Is everyone at a stable point for a 3.0.12 release?Not really, mainly because I know the optimizer is broken. Not that it wasn't any less broken in 3.0.11 :)
fcntl-locking even without contention is just plain slow. Don't you think having a local copy would speed things up? It may not, but my guess is that especially with heavy user-cache usage, lock contention is an issue. Remember that we hold the lock for the duration of the memcpy on a user cache hit.I'd also like to explore having a way to optionally configure a local process-level quick cache that wouldn't require any locking.I'm having trouble profiling a multi-process lock contention scenario with oprofile. I anybody's had success with oprofile, please advise.
An malloc() cache of 20 entries doesn't sound too hard to do. Especially since there's none of the pending member hacks in a process (what about TSRM pthread folks ?).Yeah, for TSRM I guess we don't gain anything, so I'd say disable it in TSRM mode. Nobody sane runs TSRM anyway. -Rasmus