Python memory use (psyco, C++)

Jun 21, 2004 32 Replies

I understand that psyco significantly increases memory use. Is that for code or data? More specifically, if I've got a memory intensive application (it might use 100's of Mbytes of data), should I expect memory use to go up significantly under psyco?



Also, for that memory intensive application, how should I expect Python memory use to compare with C++? I'm really only interested in data; the memory needed to store the code is almost certainly insignificant in either case.



The data is a large number of small objects, interconnected in various data structures, not just one huge block of raw data.



I know all of the above is very vague, but I'm just trying to get a rough idea if a Python implementation is feasable (or at least plausable). If a C++ version takes 300 Mbytes and a Python version takes 1 Gig, that's probably not going to work. Are there any rules of thumb I could use to get a first-order estimate?


I'd say lumber costs (retail) times about 3, should get you in the ballpark. Higher if it's a particularly difficult species of wood to work, or if other advanced techniques are required. Of course, if you have to buy a new tool to do the job, half of that cost should be added as well.

Hope this helps...

Arrggggh. I posted that to the wrong newsgroup by accident. My bad.

Roy Smith wrote in news: snipped-for-privacy@reader2.panix.com:

That's OK, Roy. Just make sure you finish that software with a nice hand rubbed shellac. ;-)

Patriarch

I have done that 2 or 3 times before also. Mine were a bit more personal however. I understand your feeling.

Hoyt W.

C++ == Neander Python == Normite.

No, that's not right. Java == Normite COBOL == Neander

Nope... Grrr...

Assembler == Neander

Huh!

Horizontal Microcode = Neander

Binary machine code = --Neander

Assembler = --Binary Machine code

C = Normite

APL = ++Normite

{ C++, Java, COBOL, Fortran, PL/I, BASIC, Pascal } = (Cro-Magnon)

Sheesh, Morris - you'll get me remembering the 360/30 and 360/40 microcode. The 360/30 had a capacitive microcode made up of mylar keypunch cards with copper coating all stacked in a pile and squeezed together with an inflatable airbag. The 360/40 had TROS for microcode - same type of cards, but tannsformer/inductance based. And then there was the "datacell"/noodle snatcher - a whopping ten megabytes of storage in a rotating pie shaped drum with mag tape like strips that were snatched out the contraption , drug over the read/wriote heads and (hopefully) stuffed back in the drum. Didn't turn out to be a long term success...

-Doug (IBM 1966-1970 - card assembler)

VB.net = Crapsman VB Script = Harbor Freight PHP = Unisaw

The follow-on microcode storage device fared much better. The Igar development effort produced the 33FD (33xx for disk, FD for "flexible disc". The 33FD was originally intended as a microcode IPL device for FS (which never came to be). Concurrent with Igar was Gulliver, a sealed disk drive with mechanicals from the labs at Hursley (thus the Winchester name applied to the technology) capable of storing 40/64MB of data, depending on model; and Lynx, a printer with type embossed on something roughly similar to a bandsaw blade (I knew I could find something bordering on topicality in this!) - all three of which survived fairly well in one form or another. [There were a lot of woodworkers in that crew; and they were the people to talked me into buying my Unisauer and mentored my first serious woodworking projects.]

Seems like everybody liked the noodle muncher except the people who relied on 'em and the people who serviced 'em. I'd really wanted to play with one but never did.

You can go anything with grep, sed, and awk.

I've never seen anyone misspeel "perl" that way before.

Oh yea! Then what IS the correct way to "peel" perl? ;^}

There are _always_ better ways than the pathetically eclectic rubbish lister.

Unfortunately, the better ways are almost always more complex, and/or more difficult to learn/use.

Define "better" in this context.

Chris (making my living writing perl, more or less)

I've never heard of joinery described that way. ;)

Wes

(trying to learn perl)

_Wall_ said so. I figure _he_ knows what he's talking about, re: PERL.

'Better' is *highly* context-dependent. For any specific, _single_, application, there is almost always 'something' that is better, for any rational ranking basis.

The rubbish-lister's advantage is that is 'good enough' for a _very_wide_ variety of things. It doesn't _try_ to be 'best' at _anything_ -- being 'good enough' _is_ 'good enough'.

It's OK, he's just sore that he can't write in Perl with his toggle switches. I look at it as the Leatherman of tools - sure, there are specialized tools that can get you the last 1% of functionality, but for 99% of what I'm doing, I can use perl for it.

The _real_ question is, ... VI or EMACS?

Dave Hinz

Oh yeah? Well, what would _he_ know about perl, anyway? Harrumpf.

Exactly my "leatherman" analogy, yup.

Dave Hinz

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required