Do you think these facts will have any undesirable impact on performance of the system (beside RAM usage)?
No, not if you have enough RAM (but if the system starts paging out memory, there will be an impact on performance, of course...).
P.S.: the copy-on-write semantics when trying to share memory between (mod_perl-)processes is generally a problem with large Perl data structures, because unless you're extremely careful and know what you're doing, Perl tends to cause write accesses to lots of the memory pages as a result of updating internal housekeeping data (flags, caching strings/numbers from implicit conversions(*), etc.), even if you only ever read the data. In other words, the pages often become unshared rather soon. In such cases, at least try to avoid implicit type conversions (like stringification of numbers).
___
(*)use Devel::Peek; my $x = 42; Dump $x; print "$x\n"; # <-- conversion to string behind the scenes Dump $x; __END__ SV = IV(0x62de18) at 0x604fa0 REFCNT = 1 FLAGS = (PADBUSY,PADMY,IOK,pIOK) IV = 42 42 SV = PVIV(0x606130) at 0x604fa0 REFCNT = 1 FLAGS = (PADBUSY,PADMY,IOK,POK,pIOK,pPOK) IV = 42 PV = 0x624fb0 "42"\0 CUR = 2 LEN = 8
The cached string (PV), the modified flags, etc. have caused write accesses at the memory location of the respective C struct that holds the scalar $x, even though it had seemingly only been read in "$x\n". Similar issues arise when taking references of $x, which causes a change of REFCNT.
In reply to Re: large perl module
by almut
in thread large perl module
by minek
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |