DeWitt Clinton wrote:
>
> On Sun, Mar 11, 2001 at 03:33:12PM +0100, Christian Jaeger wrote:
>
> > I've looked at Cache::FileCache now and think it's (currently) not
> > possible to use for IPC::FsSharevars:
> >
> > I really miss locking capabilities. Imagine a script that reads a
> > value at the beginning of a request and writes it back at the end of
> > the request. If it's not locked during this time, another instance
> > can read the same value and then write another change back which is
> > then overwritten by the first instance.
>
> I'm very intrigued by your thinking on locking. I had never
> considered the transaction based approach to caching you are referring
> to. I'll take this up privately with you, because we've strayed far
> off the mod_perl topic, although I find it fascinating.
>
> > - why don't you use 'real' constants for $SUCCESS and the like? (use
> > constant)
>
> Two reasons, mostly historical, and not necessarily good ones.
>
> One, I benchmarked some code once that required high performance, and
> the use of constants was just slightly slower.
>
> Two, I like the syntax $hash{$CONSTANT}. If I remember correctly,
> $hash{CONSTANT} didn't work. This may have changed in newer versions
> of Perl.
>
> Obviously those are *very* small issues, and so it is mostly by habit
> that I don't use constant. I would consider changing, but it would
> mean asking everyone using the code to change too, because they
> currently import and use the constants as Exported scalars.
>
> Do you know of a very important reason to break compatibility and
> force the switch? I'm not opposed to switching if I have to, but I'd
> like to minimize the impact on the users.
>
> > - you probably should either append the userid of the process to
> > /tmp/FileCache or make this folder globally writeable (and set the
> > sticky flag). Otherwise other users get a permission error.
>
> As of version 0.03, the cache directories, but not the cache entries,
> are globally writable by default. Users can override this by changing
> the 'directory_umask' option, or keep data private altogether by
> changing the 'cache_root'. What version did you test with? There may
> be a bug in there.
>
> > - why don't you use Storable.pm? It should be much faster than Data::Dumper
>
> The TODO contains "Replace Data::Dumper with Storable (maybe)". :)
>
> The old File::Cache module used Storable, btw.
>
> It will be trivial to port the new Cache::FileCache to use Storable.
> I simply wanted to wait until I had the benchmarking code so I could
> be sure that Storeable was faster. Actually, I'm not 100% sure that I
> expect Storeable to be faster than Data::Dumper. If Data::Dumper
> turns out to be about equally fast, then I'll stay with it, because it
> is available on all Perl installations, I believe.
>
> Do you know if Storeable is definitely faster? If you have benchmarks
> then I am more than happy to switch now. Or, do you know of a reason,
> feature wise, that I should switch? Again, it is trivial to do so.
I've found it to be arround 5 - 10 % faster - on simple stuff on some
benchmarking I did arround a year ago.
Can I ask why you are not useing IPC::Sharedlight (as its pure C and
apparently much faster than IPC::Shareable - I've never benchmarked it
as I've also used IPC::Sharedlight).
Greg
>
> > >I have some preliminary benchmark code -- only good for relative
> > >benchmarking, but it is a start. I'd be happy to post the results
> > >here if people are interested.
> >
> > Could you send me the code?, then I'll look into benchmarking my
> > module too.
>
> I checked it in as Cache::CacheBenchmark. It isn't good code, nor
> does it necessarily work just yet. I simply checked it in while I was
> in the middle of working on it. I'm turning it into a real
> benchmarking class for the cache, and hopefully that will help you a
> little bit.
>
> Cheers,
>
> -DeWitt
