Python memory use (psyco, C++)

[Roy Smith]

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?

[Dave Hinz]

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...

[Roy Smith]

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

[patriarch]

Roy Smith wrote in news: [e-mail]:

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

Patriarch

[Hoyt Weathers]

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

Hoyt W.

[patrick conroy]

C++ == Neander Python == Normite.

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

Nope... Grrr...

[Doug Winterburn]

Assembler == Neander

[Morris Dovey]

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)

[Doug Winterburn]

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)

[tillius]

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

[Morris Dovey]

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.

[Buck Turgidson]

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

[Dave Hinz]

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

[Al Reid]

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

[Robert Bonomi]

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.

[Chris Richmond - MD6-FDC ~]

Define "better" in this context.

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

[clutch]

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

Wes

(trying to learn perl)

[Robert Bonomi]

_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'.

[Dave Hinz]

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

[Dave Hinz]

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

Exactly my "leatherman" analogy, yup.

Dave Hinz