Probably not useful, unless it's very bad at it's own memory management.
eAccelerator stores compiled PHP scripts in shared memory and executes
code directly from it. It creates locks only for a short time, while
searching for a compiled PHP script in the cache, so one script can be
executed simultaneously by several engines. Files that can't fit in
shared memory are cached on disk only.
https://github.com/eaccelerator/eaccelerator/wiki
Edit - Adding notes for memory settings which outgrew a comment.
By default eaccelerator will allocate up to the OS available "shared memory"
; The amount of shared memory (in megabytes) that eAccelerator will use.
; "0" means OS default. Default value is "0".
eaccelerator.shm_size = "0"
A Linux box will most likely be 32MB (33554432 bytes):
$ sudo sysctl -a | grep kernel.shm
kernel.shmmax = 33554432
kernel.shmall = 2097152
kernel.shmmni = 4096
kernel.shm_rmid_forced = 0
I doubt your compiled code would even reach that size, maybe if you're running a large number of virtual hosts for lots of people you and have a huge range of PHP?? It appears all support for storing extra "Session data" and "User data" has been removed from eAccelerator so you don't worry about any of that.
If you reconfigure the shared memory to be a bit higher, then yes you are unlikely to fill or even touch 256MB of disk. I'd even be tempted to turn the disk cache off with eaccelerator.shm_only = "1"
as your talking about diminishing gains when adding the latency of going out to disk to fetch compiled code. The best way to find out is do some production like load test of your site(s) when it's set up.