On Fri, 2005-12-16 at 03:33 -0600, Chase Venters wrote: > Well, I should have been more clear here that I was no longer talking about > prefork. What I meant by COW here was actually that if you were going to use > multiplicity with Perl_clone, since the threads would share memory, Perl > would either need to: > > (a) create a copy of all variables; > or > (b) use a thread sync primitive like an rwsem and do its own COW on this data.
I don't know much about threads, but I'm pretty sure it does a. > What I'm > not clear yet on in my study of perlguts is how much overhead is associated > with a hash, because while the individual structures aren't huge, there could > be a lot of them. It will probably be big. Perl structures tend to use several times the size of the actual data they store. > 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 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. > 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. - Perrin
