Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re^4: Finding memory usage of perl structure efficiently

by dpavlin (Friar)
on Jun 27, 2010 at 22:20 UTC ( [id://846806]=note: print w/replies, xml ) Need Help??

in reply to Re^3: Finding memory usage of perl structure efficiently
in thread Finding memory usage of perl structure efficiently

I'm using 64-bit kernel with 32-bit userland. It might make sense to bump it up to 16384 so 64-bit users won't have to touch source at expense of small memory increase.

  • Comment on Re^4: Finding memory usage of perl structure efficiently

Replies are listed 'Best First'.
Re^5: Finding memory usage of perl structure efficiently
by BrowserUk (Patriarch) on Jun 28, 2010 at 04:47 UTC

    A year and a half ago when I release 0.72, the preponderance of people were running 32-bit and 8192 was already double what they required (most 32-bit processes are limited to 2GB and 8192 allows for 4GB). And even most 64-bit systems maxed at 4GB.

    But, Moore's law moves inexorably on, and 8GB is probably about right to cover the next couple of years or so. If I decide to release a forked version, I will increase the default to 16384. I have been waiting for the appearance of *a* bug against the current version, but none has emerged..

    There is a bug report, raised against 0.71, that also affects 0.72, but I consider that a bug (or rather, a regression), in the perl core. This because the the "bug" did not happen prior to the 5.10 release; and because it affects (and afflicts) other core-only code, quite outside of 0.72.

    As such, patching D::S to fix this is a mere band-aid that would have to be replicated by every other module and program that uses $#array.

    The obvious, simple and correct solution to that problem is to regress the core change that promiscuously converted every reference to $#somearray into a costly (and often pointless) application of 'magic', whether it was required or not.


    0] Perl> @a = map [], 1 .. 1e6;; 0] Perl> ## At this point, the process is using 195MB RAM.;; 0] Perl> $s = $#{ $_ } for @a;; 0] Perl> ## At this point, the process is using 395MB RAM.;;

    It is patently f****** ridiculous that simply checking the size of an array, costs 200 bytes of memory.

    Even more ridiculous, is that the raiser of the "bug", who is entirely competent to be aware of this, couldn't see past his own prejudices, and raised the "bug" against D::S, rather than as a regression against the core. But that is just par for the course.

    And if that sounds bitter, it's because it is. And that tempts me to post a meditation that has been brewing in my head for 3 or 4 years now. Provisional title: "This community is as fractured and dysfunctional--and living in the same denial--as the USSR was in the late 1989 and early 1990."

    If you want to read that meditation, then it is not enough to vote yah or nah. You will also have to encourage all your friends to vote. Because that post will only materialise if the absolute(*) vote of this post is >50.

    Ie. Unless the vote tally for this post reaches greater than +|- 50, I will not make the meditation.

    (*)Explanation of the logic behind making this an absolute limit available by /msg on request.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://846806]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (5)
As of 2024-05-22 01:58 GMT
Find Nodes?
    Voting Booth?

    No recent polls found