Personally, I find the whole, "throw memory at the problem, hardware is cheap" philosophy abhorent!

Maybe this stems from starting out on 'big' multi-user systems with a whole 128 Kb of 'core'(¹) memory used by up to 32 users at a time.

¹ Tiny ferrite beads threaded--lovingly, by hand by japanese ex-perl divers--around each junction in a 2D grid of thin copper or gold wires. Quite fast (in its day) and hugely expensive!

Maybe its because I see programs like Xara3D that can render 3D objects, with 24-bit surface texturing and 3 24-bit light sources, whilst rotating the object in 3-dimensions and scaling it in real-time!. And all this on my poor ol' 233MHz pentium whilst I am changing the position of the light sources, the speed and direction of the three rotations and scaling the objects by dragging sliders. The changes are immediate.

The executable is just over 1 MB in size.

I compare this with other top name brand graphics applications and they are huge (100MB+ with configuration files and registry usage more than 1 MB each), uncompromisingly horrible to use interactively and soooo sloooow!

It also has to do with the notion that it is very rare for any computer system to be doing just one thing these days. I always have a multi tabbed browser session running. 20+ files open in my editor, half a dozen command line sessions, a download running in the background etc. etc. I know that this is nothing remarkable. The point is that if every program adopted the philosophy that when its running, it is going to routinely grab as much memory and cpu as it feels like with no regard to what else is running in the system, then my current way of working would require much more highly specified machine than I have.

So, I frequently reject software that I feel consumes more memory or cpu than is necessary and especially stuff that is written with the philosophy that while it is running, it owns the box.

For me, optimising memory and cpu usage isn't about saving a few bytes here and there or knocking a few seconds off of the runtime of a long running program. It's about not consuming what you don't need to consume and realising that software doesn't run in isolation.

Using a memory hungry algorithm rather than a more complex less hungry one may save the individual programmer a few minutes or hours of design or coding, but every user of the result pays the penalty.

This may be ok for one-off, bespoke packages aimed at corporate environments that have the money to throw hardware at the problems the philosophy creates, but it's also selfish and impolite!

The instructor was praising how VB programmers didn't need to worry about the memory they take up with their programs, basing his opinion on the amount of memory modern desktop systems have.

The instructor is an idiot. A programmer should always keep in mind how much memory and CPU time their code is going to use -- an eighteen wheeler is not required to move a carton of milk home from the corner store.

Would this instructor read a 40G log file into memory before processing it? I sure hope not. Unless, of course, s/he was being facetious.

The professors statement was a sweeping generalization. Sweeping generalizations are rarely true in all cases. You should always think about your resources.

A good thing about languages/systems that garbage collect memory is that you don't have to worry about deallocating memory when you're done with it. This is great because you most likely avoid dreaded memory leaks that can be difficult to find. This is especially beneficial when the developer does not have much experience managing memory.

On systems that don't garbage collect memory you have to be smart and do it yourself. When you have to manage all of your memory you probably have more control over what, when and how much you use. Many of these languages can be faster if the developer knows what (s)he is doing.

In short you want your application to run quickly and efficiently and not be a resource whore.

VB is great for what VB does, C/C++ is great for what it does, DBMS are great for what they do. And since I'm posing on perlmonks I better say Perl is great for what it does! You just need to choose the right tool for the job. I wouldn't use VB to write a device driver. Personally, I'd use Visual C++ to do it on Windows. Don't use a screwdriver when you need a hammer and vice versa.

to learn PERL

What's this language "PERL" you are talking about?

Am I wrong to disagree with the instructor and feel that the more memory a program requires, the slower it is likely to run?

Yes. You would also be wrong in believing that the more memory a program requires, the faster it runs, or that the amount of memory required doesn't influence the running time.

Memory usage influences running time. Accessing the memory takes time. More memory means that you are more likely to get cache misses, increasing the running time. More memory may mean more swapping, increating the running time as well. OTOH, using less memory could mean having to recalculate stuff more often, also increasing the memory time. Less memory could mean less buffers, meaning having to consult slow resources more often, increasing the memory time.

So, whether more memory means a program runs slower or not depends on many factors, and you can't simply say it runs slower or faster.

Abigail

Probably this PERL

------
We are the carpenters and bricklayers of the Information Age.

The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

It is probably fallacious to say, "I learned Perl" (or any other programming language). Nobody can learn any nearly infinately complex thing in its entirety in a finite amount of time with finite intellectual resources. (No insult intended: Only Stephen Hawking lacks the finite qualifier to intellectual resources. *smirk*) But you can learn enough to accomplish what you want to, in style, while having fun at the same time.

And it is always correct to refer to Perl, the language, as Perl. The executable itself is called perl (or perl.exe on a Microsoft infected system). And PERL refers to nothing I know of, though the higher gods have been known to say that Perl (whos letters are P.E.R. and L.) stands for Practical Extraction and Report Language, as well as, Pathologically Eclectic Rubbish Lister.

So you'll avoid getting the gods, saints, and understudies in a tizzy by avoiding referring to Perl, the language, or perl, the program, as PERL.

Regarding your second question:

Programmers must always worry about finite resources, and professors should worry about absolute statements with infinate ramifications (no pun to RAM intended).

Increased memory usage leads to increased memory swapping, a decrease in finite resources available to other simultaneously running programs, and in fact, a flat out exhaustion of avaliable memory. In small programs, perhaps memory usage is less of a concern. But it is the aggregate of many small blocks of code that come together to create true bloatware such as Microsoft Internet Explorer and Visual Basic libraries themselves.

Memory usage also can relate to speed in that moving a meg or two around takes more time than a byte or two. Memory usage relates to speed in that slurping in a 2gb file to read a 100 byte section two kilobytes into the file is a much more time consuming process than just reading in what you need.

And memory usage has many other ramifications as well. It cannot be assumed that different levels of memory usage will not have different effects on speed, as well as other measures of efficiency and performance.

That said, sometimes a more memory intensive method happens to be an easier method. Slurping in a whole 50k file to look for and edit the 10th line might happen to be the programming-quickest way to accomplish a particular task. But any selected method of solving a problem should weigh all of the side effects.

Dave

"If I had my life to do over again, I'd be a plumber." -- Albert Einstein

Then I shall thank you. I had not realized that referring to Perl as PERL would have upset anyone. My appologies. As for the rest of these comments, I appreciate them, they are a great help to my thoughts. I was starting to feel so alone in my native world, so many people decide to keep the mysteries of programming to themselves in my home. . . Those that don't, disappointment with being so, uncaring of the other persons computer. . .

Again, thanks to you all.

---

"I have said, Ye are gods; and all of you are children of the most High." - Psalms 82:6

1. There is no equivalent for "use strict" in PHP.
2. There is no concept of a namespace in PHP.
3. PEAR does not compare to CPAN.

1. There is nothing wrong. I think PHP solves a particular problem (one that pertains to HTML), while Perl solves more general stuff.
2. If a program takes up more memory, then it is more likely to be swapped out of the memory more often, I think.

Don't be a litterbug

Don't waste memory just because it seems computers have large memory spaces. Similarly, don't abuse CPU cycles, intentionally use bad algorithmns, ....

Comprehensible code is always the priority, but keep an eye out for opportunities for efficiency; avoid wasteful techniques. In particular, avoid things that are silly, wasteful, meaningless, and don't contribute to effectiveness. I am especially irritated when programmers pass an array or hash reference into a routine, then copy it to a real array or hash. If the object is known always to be small, you could consider copying the whole thing into the routine.... but what if someone decides to use your routine for a much larger data set. Instead of copying data, learn to use the arrow to dereference array references. It isn't so difficult!

Don't sweat the small stuff

If it's never going to affect more than 0.01%, who cares how efficient or inefficient it is?

Figure out your priorities

Let's say an object/structure takes up 128 bytes. If we have a loop which iterates a million times, options include:

1. allocate, use,and deallocate a million objects
2. allocate, and use a million objects without deallocating them
3. allocating one object, using it a million times to store different data, then de-allocate once.

Option 1 involves a million allocations and a million de-allocations, all of which take time, but requires only 128 bytes at any one time.

Option 2 takes a million allocations and no de-allocations, so that saves some time. On the other hand, it requires 128,000,000 bytes of memory. How much time will be used in swapping memory to disk?

Option 3 uses only a single alloaction and deallocation, and takes only 128 bytes, but there is a risk for unclear code in the procecss of saving memory.

Don't optimize too early

The first priority is to develop a program which is complete and correct. Then you can profile the system to consider whether it could be better.

--
TTTATCGGTCGTTATATAGATGTTTGCA

If you can't do ... teach
If you can't teach ... get Microsoft Certified and teach VB

Would it not be better stated as:

Those who can - do

Those who can't - teach

And those who can't do that - become MicroSoft certified and teach VB

jdtoronto

Every day I talk to people who still work in Cobol. It has a place in the world. So does VB - I just haven't found a place for it because I am no fan of closed proprietary languages and systems. I have also been in situations where a VB developer was being paid far too much money and delivering far too little. Five years ago, as a PERL neophyte but a 45 year old engineer I wrote a command line Perl programme in 2 days to do a job. My employer contracted for a VB application to write a GUI version. It never completely worked but cost him $70,000. Just three months ago he asked if I could take a look and see if I could fix some of the worst bugs in it. I took a look at it, threw it in the bin and rewrote the whole thing in Perl/Tk in five days for a total cost of $US 5000.

The difference? I knew what the programme had to achieve and had all the resources of CPAN to handle network and serial port things. I even added some SNMP stuff which the Microsoft guru's had said was far too difficult and would require a complete re-write in C++.

Any language can be good in the right hands and when doing a job it is suited to. There is nothing fundamentally wrong with PHP - in it's place! I have a web app suite that is 27,000 lines of perl code (all the HTML is handled with HTML::Template and there are nearly 300 templates). I cannot imagine attempting that in PHP.

But I sometimes wish I knew PHP when I just want a simple single form application that is only going to be used for a week. A quick and dirty solution would sometimes be handy!

Don't be dissuaded, I am sure youi will hear from others about how we used to do things with 8k words of core and little or no mass storage at all. How well I remember those days, we could build an entire text editor to run in memory complete with buffer space, pity you had to write it out to paper tape to be able to go backwards beyond the buffer!

I do like the idea of asking your instructor how to do a diff on two 100gb files! Tickles my fancy :)

jdtoronto