Maximum PC

I know we have tones of memory and stuff, but does anybody care to write efficiently anymore. Network connections can be just as valuable as memory or mips. It has gotten horrible if I try to tether. Yahoo is the worst.

Write what efficiently?

Programs. Compared to the olden days, many of today's apps are true fatware.
Back when computers had small amounts of RAM, programmers had to cram a lot of code into a small footprint.
For example, I used to write TI-BASIC code for TI 99/4A computers. With only 16Kilobytes of RAM to work with, you learn early on to write with economy in mind.

If you want the conveniences of high level languages, you have to trade performance and resource requirements. Otherwise, we might as well be writing in assembly to get the most bang for the buck. But anyway, today we have gigabytes of memory readily available, why not use it?

Also 16KB of RAM? Pfft. Try 512 bytes. Running something RTOS like.

Personally, I think there is a grain of truth in what you're saying. In addition to a fairly substantial academic background, I have about six years of commercial industry experience. There has probably been two dozen occasions when I've come across some legacy code that I could improve substantially. Unfortunately, managers will very seldom give you the go ahead to fix existing code. It makes them look bad (ie why didn't your team get it right the first time we paid for it). To be fair, a lot of buggy, slow code was written over twenty years ago.

I believe the primary reason for 'fatware' becoming more prevalent is the number/variety of users. The combination of less sophisticated users and the desire to have 'software suites' that perform multiple tasks for the user is the primary force increasing the size of applications. This has been an enduring theme in the classic Vi/Emacs war. Even when I was a dedicated Vim user, it was pretty clear (to me at least) that Emacs had won the war.

I love hearing about older software development experiences. What kind/types of applications were you writing? BTW, BASIC isn't exactly the most efficient language; The same application written in FORTRAN would probably be smaller and significantly faster.

While we could blame legacy code for causing bloating, some software released in the past 5 years or so, like Chrome, will gladly eat your RAM. I think the last time I was using it (I stopped using it ever since about the start of the year), I could have somewhere between 50-100MB per tab. And for websites that don't appear to be resource heavy.

Unless Chrome was forced to use some inefficient web standard for that page.

Plus some coding habits I found can lead to some extra bits of code. For instance, when I'm writing something to control an LED, I have an explicit "LED_On" and "LED_Off" function, rather than "LED_State(bool Enable)". Or in my last work project, Red_LED_On(), Green_LED_On(), etc. Sure, I could probably save a few lines of code by having some LED_On(uint8_t Color, uint8_t Enable) function. But I also just like reading something that's clear.

Another edit:
I also want to note that back then, since memory was precious, anything that had to deal with multi-media had either a lot of memory (For the time), or it had to procedurally generate it. I think procedural generation is kind of going the wayside because... well we have memory.

I wrote a few simple games; one was a gangster FPS with fairly decent graphics and sound. Another was a crude business tycoon sim. One program was (believe it or not) a piano tuning utility that I'd tested against tuning forks. No way did I just get a table of frequencies for a piano and plug the data in... no, I developed do-loop routines with lots of trial and error to generate and fill a big array with the proper frequencies to within 0.001% accuracy.

I'd used TI-BASIC because assembly required some quite expensive add-ons... I don't remember if it was a cartridge or peripheral, but I do remember it was expensive. I wrote everything so that all a person needed was the TI console, a cassette player/recorder, and a TV set with sound. Did I sell anything? Yup, mostly to grade schools, via magazine ads.

As far as FORTRAN goes, that's what I'd originally learned to code with a year earlier at University of New Brunswick. We used punchcards and a monstrous IBM mainframe. We were limited to 30KB.

Putting the software engineering aspects aside (but I tend to agree that LED_On and LED_Off are clearer and less error prone), I would have thought that the difference in memory consumption would be negligible. Did you do some testing that confirmed a difference? If so, what was the cause?


Not that I wish to become the defender of Chrome, but I have about twenty tabs open currently and the largest is 25MB with most somewhere in the 6MB to 10MB range. The only time that I've ever really had trouble with Chrome is when a page has (what I assume) are badly written flash applications (as killing the Shockwave Flash plugin has always cleared up the problem).

LOL ... 30KB? Talk about being spoiled. =)

I haven't done any explicit research on it, but I doubt there's any real impact on something simple like this. Given my experience with the MSP430 I used, which is probably how RISC works in general, I could see a single function looks like this when compiled:



Versus this

So you're doubling the code space from two instructions to four. This also consumes no memory anyway since the value is either in a register or is immediate.

For something more complex, say a periph_setup function versus a periph_init and a periph_deinit function, there wouldn't be much impact I would think. But it really depends on what the complimenting functions are trying to do.