Program space

Nope.  It gets optimized by the compiler to the same opcodes.

@lydara

Thanks.  I prefer to write it "longhand" as i find it easier to understand when i re-read it later on.

@tigs62  Then just never try reading LISP!  Ugh...

Hi @tigs62,

  You attitude is indeed the best one --- write programs in a fashion you can understand.

----------

Brian Kernighan is credited with the quote:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

and he co-wrote with Ritchie, the first book on C programming --- perhaps one of the most influential programming books ever written.

[ https://en.wikiquote.org/wiki/Brian_Kernighan ]

------

By the way, compilers have become much smarter over the years, so it is now rare for tweaking code to 'help the compiler' to make a significant improvement to the running time. Changing the algorithm, so that the whole task becomes shorter, can be a different matter.

A possible exception to the above rule, might be an interrupt handler, where the handler is called a great many times per second, so every machine instruction counts. But even here, get it working first with 'simple code', then tweak if you really must.

"Changing the algorithm, so that the whole task becomes shorter, can be a different matter."

I think a slightly different interpretation of this is writing the program in a different fashion. 

One example of this might be coding the actions in a somewhat linear fashion (often resulting in something slightly removed from spaghetti code versus using look-up tables. 

A truly smart compiler would have a switch to allow you to determine whether execution time, memory (either Progam or Data) space, or a combination is more important.  Though I guess with today's computers memory space has often become a trivial issue.

Larry

@larry-manson

I would say that it's the programmer's job to decide which is the more important of speed or memory and to select algorithms to suit that choice; although today's programmers would be shocked at having to fit programs into the 64K that was available for the old DEC and Data General machines.

It's the compiler's job to convert the high level language to an optimized set of machine instructions.

I agree with it the programmer's responsibility to decide the value of memory vs. execution speed. It's used to be the compiler's responsibility to give him the tools to help execute that decision. 

64k was a wonderland when I started. 

Spent many hours working with an IBM 1130 with an entire 8k of core. We were doing structural analysis on buildings.

Later I wrote embedded applications that fit in a PIC1654 with 512 12 bit words of program memory and 32 8 bit RAM registers. 

Yeah, I would have loved 64k!

Larry

Posted by: @will

although today's programmers would be shocked at having to fit programs into the 64K that was available for the old DEC and Data General machines.

Back in college in the 1990s, I lead a team of three on a senior project--a non-academic student information database.  It ran Pascal with embedded SQL on VAX/VMS.  Only a little over 300 fields, 18 tables, a few views, screens, & reports.  Yet it ran _HORRIBLY_ slow, like TWO MINUTES to bring up a single screen!

Luckily our department chairman had a personal friend--who was "the DEC CEO's hired gun."  The kind of guy who if the CEO heard they might lose an account, got the call from the CEO's secretary with plane tickets for him that same day!  He came to Wofford College and graced us with an entire day of donated time. 

Took him about five minutes to realize what we students had done wrong.  He didn't even ask, just immediately began dumping the entire database structure to text and the data to an export.  He then said "While that runs, let's share lunch and then come back to teach you all how to optimize a database for both function & for the hardware it rides upon."  This guy taught us more in one day than some of our other courses conveyed in an entire semester! 

We had created our documentation as we coded.  We did this by "coding" in WordPerfect on the Mac, then cut & paste into Kermit terminal on the Mac.  Every time the db structure changed, we just coded & copied in the ALTER DB statements.  _Hundreds_ of sessions with changes...  Which then resulted in any given db record being physically strung out over dozens of storage pages!  And with the entire college pounding against the same pool of memory, our chaotic junk couldn't even keep enough cached in RAM to avoid the order-of-magnitude hit of going to hard drives.  Ow! 

Once we nuked the db and recreated it in "final" form, added some indexes, and optimized page boundaries....any screen would pop in milliseconds--less time than it took to enter the command!  😀  Thanks Bill!!!

No matter how good the compiler, there is _always_ going to be value in well-crafted human designs.

@lydara

Yeah, I loved RDB on the VAX much better than SQL. I hated to see the VAX fade away.

To elaborate on the above, MAYBE w = w + 1 gets optimized to the same thing as w++ and maybe it does not.  It can depend on the quirks of the optimizer.  Even worse, it might do so with one version of the compiler and not the next but then do so again on the one after that.  I have seen it happen with other code generation.

As an aside and a warning, NEVER write w = w++ or w = w--.  This is erroneous code.  It may work the way you intended or it could leave you with the original value of w.  It depends on how the code is generated.  I used to have a link to a paper that documents all manner of things that the compiler may not complain about because they are syntactically correct but which are not guaranteed to work in a specific way and which should always be avoided.  If I can find it, I will post it here.