On 12/5/05, Ed Summers <[EMAIL PROTECTED]> wrote:
>
> > Am I right that this amounts to less than 1Meg (EastAsian.db +
> > UTF8.db)? Depending on your system and your needs (more
> > speed?), that may not be considered large and might fit into
> > memory fine. Otherwise, I think any of the in-core (non-DB_File)
> > DBM files ought to suffice for that amount of data.
>
> Which in-core dbm modules are these? I thought DB_File was the defacto
> standard for doing this...
Excerpt from `perldoc AnyDBM_File`:
DBM Comparisons
Here's a partial table of features the different packages offer:
odbm ndbm sdbm gdbm bsd-db
---- ---- ---- ---- ------
Linkage comes w/ perl yes yes yes yes yes
Src comes w/ perl no no yes no no
Comes w/ many unix os yes yes[0] no no no
Builds ok on !unix ? ? yes yes ?
Code Size ? ? small big big
Database Size ? ? small big? ok[1]
Speed ? ? slow ok fast
FTPable no no yes yes yes
Easy to build N/A N/A yes yes ok[2]
Size limits 1k 4k 1k[3] none none
Byte-order independent no no no no yes
Licensing restrictions ? ? no yes no
So sdbm is the one that is sure to have its source in the perl
distribution. I'm guessing that most/all of the CPAN testers
have bsd-db installed already, therefore the tests don't fail.
As for the memory, it's not really the memory which I'm concerned
> about as much as it is the time it would take to build the database
> everytime someone used the MARC::Charset module. Perhaps I'm falling
> victim to the curse of premature optimization again though. If I had a
> text file of 16,000 mappings that was read in everytime someone did a:
>
> use MARC::Charset;
>
> would people be put out? I imagine folks in mod_perl environments
> wouldn't care too much--although a MB of ram for each apache process
> has a way of adding up. At least for high volume sites.
I think you're correct to be conservative. I've been spoiled
by servers with lots of memory, so my judgement may be in
question. :-)
--
Brad
