On Fri, 16 Dec 2005, Perrin Harkins wrote:
It will probably be big. Perl structures tend to use several times the
size of the actual data they store.
That's what I'm worried about then I suppose.
is this root hash, its keys / values / etc stored along with variables, or is
it in the op tree?
I assume that it's stored in exactly the same way all the other
variables are stored.
I wonder then if Perl would be smart enough to understand that the data is
constant and not copy it with Perl_clone()? I suppose what I really should
be doing here is writing a test as a perl embedded app that does various
things to test out clone's behavior.
I can't put the data in SQL for performance reasons.
Have you tried? It's hard for me to believe that the data can't be
broken down in a way that would make external storage possible.
Actually tried? No. But the data is in essence a big table of information
about how to build SQL queries from method calls, validate/convert the
information in the process, and pack it into objects. Having to first
fetch the model itself out of SQL (its structure not even lending to easy
storage in such a DB) would be clunky / awkward, and would basically
involve an extra query or set of queries against a table for every
request.
Now, admittedly, I'm an extreme freak when it comes to optimizing for
performance. In the age of J2EE, it's how I make my stuff shine. Seeing
low-ms response times from mod_perl apps makes me smile.
And BDB would be dependency creep, which
is quite difficult to fight in perl sometimes (that's just because there are
a zillion useful CPAN modules) :)
Personally, I don't fight it. I just use zillions of CPAN modules.
Genearlly so do I. And so do the authors of those modules. Then one day
you're installing Net::SSH::Perl and you realize that it pulls in fifteen
module distribution dependencies once everything is accounted for.
I now understand the meaning of autosplit :)
- Perrin
Thanks again for your remarks.
Cheers,
Chase
