On Feb 26, 2005, Sam Tregar wrote:
On Sat, 26 Feb 2005, James Keenan wrote:
[snip]
Has anyone else encountered these problems and developed a workaround?
The best workaround is to just switch to the file_cache. In most
cases it's just as fast as shared_cache due to the OS caching file
access and it's a heck of a lot easier to work with (no arbitrary
limits, no need for special tools to clear the cache, etc).
-sam
... and Cees Hek wrote:
I would seconds Sam's suggestion here. The shared memory caches are
not
really worth the trouble, and are actually surprisingly slow. If it is
absolutely necesary for the cache to be in memory then setup an
in-memory filesystem (not sure how to do that on OSX). However, it is
often best to just let the OS handle the file system caching directly.
The OS is very efficient at keeping the most often accessed files in
memory for quick access.
Thanks, Sam and Cees for such a quick response. I should perhaps
clarify that my interest in solving this problem was not to maximize
H::T's speed. Rather, as part of the Phalanx Q.A. process
(http://qa.perl.org/phalanx), I'm working with some of my fellow
hackers from Perl Seminar NY on H::T. One of the things we like to do
is to improve the extent to which a given module's test suite provides
coverage for the module's code. Having all of a module's features
installed is important here. Fortunately, besides a couple of Macs we
have Linux, FreeBSD and Windows boxes available, so we'll probably be
able to get the shared cache feature running on one of them and be able
to take a look at the test coverage in that area. Thanks again.
Jim Keenan
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
|
