Todos APC 4.0

Task	Status	Schedule	Contributors	Description
Multiple cache support	Done	4.0.0a	shire	Rework configuration , code, and apc.php, and API to support multiple user and file caches. INI configuration will not require changes as part of the 3.x->4.x upgrade path, however the API will not require any changes unless multiple user caches or file caches need to be specified. Some changes may be necessary for the apc_cache_info() functionality.
Plug-able Expunge Methods	In-Progress	4.0.0a	shire	Add ability to easily switch out and configure different expunge methods on the C level, consider PHP space
LFU Expunge	In-Progress	4.0.0a	shire	Add Least Frequently Used Expunge method
None Expunge	Done	4.0.0a	shire	Add “None” Expunge option to fail on new inserts rather than expunging entries
CSV Export	Done	4.0.0a	lucas, shire	Add ability to dump CSV cache values from the apc.php browse page
Moving window statistics	In-Progress	4.0.0a	shire	Add generic window statistics tracking mostly for use with the apc.php page. ie: hit/miss rates etc
Windows Compatability	In-Progress	4.0.0a	kalle, pierre, shire	Ensure we have windows compatability and testing
mmap replacement for windows	??	??	pierre, kalle	Implement a replacement for mmap on windows
TSRMLS_FETCH()	In-Progress	4.0.0a	shire, kalle	Remove as many TSRMLS_FETCH() calls as possible or in perf. critical regions to improve TS performance.
Documentation	Not Started	4.0.0a	shire	Need to update documentation both in code (TECHNOTES) as well as in the official PHP documentation (location?) or wiki so users know about changes and can better get up to speed with APC. Should also put together an upgrade quickstart guide.
apc.php cleanup	Not Started	4.0.0b	shire	apc.php page still needs lots of fixing, additional features etc. If you're interested in helping I have a detaild list
on-disk cache (.phpc)	In-Progress/Experimental	4.0.0b	shire	Ability to dump compiled opcodes to disk per file (ie: .phpc files) so large code-bases such as CLI can get a speed improvement, as well as being able to distribute .phpc files as part of a push process to production servers so source code isn't on the remote machine.
Spin-lock stabalization	In-Progress	4.0.0b	shire	Spin locks are stable except for a signal handling problem in Zend. A patch has been prepared and needs to be tested/integrated into a PHP release. We need to test further on windows, finalize the patch, and get it into core. If this will be delayed including a patch with APC may be useful for some looking to get gains from this.
Windows locking	Not Started	4.0.0b	shire, pierre, kalle	Sounds like we need to look at our options for windows locking so we have a good, stable, efficient option that works on both Win and Unix flavors. Spin locks would be my first choice, but we need testing of support on windows and improvement of the signal handling problem for stability.
Virtual Host/Location	In-Progress/Partial	4.0.0a	shire	With multiple cache support, the idea of separating files or user cache values based upon the virtual host or location became easier to support. Add a location or virtual host option to the per-cache configuration, essentially what the file cache filters option currently supports on the 4.x branch. This will automatically limit or direct file/user entries to the appropriate cache.
Hash stats/improve file hash	Not started	4.0.0b	shire	We currently don't have stats for our hash collisions/performance, so we should add some stats that can be enabled/disabled here without affecting performance. We should then eval. the performance of the hash() function used for file device/inode and see if it should be more robust or if it's current performance is acceptable

Research

Task	Status	Schedule	Contributors	Description
Multi-Server synchronization	Researh	n/a	shire	If we could determine an acceptable behavior it would be advantageous to have a multiple-server synchronization either directly between APC installs, or more likely to some backend server such as memcached. This would allow, for example, taking the top-X hits from memcached and placing them in an APC cache. This scenario would probably also require a write-thru to memcached or other back-end.
Key Groups	Researh	n/a	shire	There are two lines of thought with grouping keys in APC, one is a high level multiple-cache grouping where each cache serves as a pool of keys for seperation/expunge purposes. Another options it have a lower-level grouping within the cache that controls behavior such as priority in an LFU list or to control items all falling out of the cache at the same type if they are associated. ie: if X is expunged also remove cache items A, B, and C. One way to obtain this behavior is through cache key prefixes. A more advanced API is alos an option, but it's less visible and will only further complicate the API. It also remains to be seen if this will be necessary with multiple-cache support in place.
no-copy	Research/In-Dev	n/a	shire	Currently we spend much effort copying values out of the cache and making sure we don't cause corruption into shared memory when opcode data is written to etc. Ideally we would reference the shared memory directly, and remove the cost of copying, especially for user variables that may never actual be modified. By modifying both Zend and APC we can create a no-refcount flag for zvals that disables both refcount inc/dec race conditions and forces copy-on-write behavior. This would also remove the need for other optimizations such as Lazy-loading, as this behavior would be more efficient.
Phar integration	Not Started	n/a	shire	Phar integration with apc_bindump API would be nice
Memory usage	Not Started	n/a	shire	Currently memory usage per key is pretty significant, we should investigate ways to improve this
Binary Serialization	Not Started	n/a	shire	Currently we do a very logic based copy of data in APC, with allocations per struct, and memory pointers that are not sequential. Ideally every key's data would be sequential and could be compressed and de-serialized by unswizzling pointers rather than re-creating the structures in process memory. This is related in ways to pool allocation, as well as possibly conflicting with memory fragmentation and no-copy optimization
fine-grained locking	Needs verification/testing	n/a	shire	Locks are current per-cache, we've already optimized locks down to pthread locks and spin locks which have very good performance, so the next level optimization would be either lock-free algorithms or finer-grained locking (or some combination of both). A patch has been developed for per-slot based locking, however my tests have yet to prove that this can provide any substantial performance gains. This should be-reverfied.

Todos APC 4.0

Research

Page Tools