Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • It would be interesting to see how many of these are reused storage allocated on pad variable introduction.

    In principle the static overhead of PADLISTS, etc could be completely shared (once allocated they never change) but the actual SV bodies they store change all the time.

    Maybe priming the callstack by invoking all of the CVs in order to share that stuff could be worth while, though it's probably not that much storage at the end of the day.

    Secondly, Stefan O'Rear has been working on memory compaction, loo

    • Sorear's work is interesting. I've used [] to get compact data as well. While writing the scripts for [] I found I'd often write the code in Perl, then would occasionally share bits of data with some Inline::C.

      But separately, my interest right now is in what happens to Linux's CoW. I've got data that is theorized to be both large and unshared between mod_perl processes. I want it both compact and shared.

      • (Note: I know nothing about this, so this may make no sense at all)

        As I understand it, the heap in Perl contains both code and variables, so if, in a forked process, a variable (which happens to share a page with some code) is changed, then that entire page becomes unshared.

        Code seldom needs to change in a new fork. Would it not be possible to separate code and variables, so that the pages occupied by your code would remain shared?

        I'd imagine that this would be a net win for memory usage in mod_perl proces