Improper fixup

The point is that '51 code should be efficient.

Why?

If I have a 9600 baud serial port, it doesn't matter if the code is capable of handling 20k characters/second.

If I need to read a voltage every second, it doesn't matter if the ISR is able to process 8k samples/second or not.

If the application fits in available memory, it doesn't matter if there is 1kB or 10kB code space free.

Only if the application hits (or may hit) a limit is it meaningful to make a decision if it is better to try to squeeze/speed up the code, or switch to faster/larger iron.

The main thing is to write correct code that is also easy to maintain. The need for optimization is more a project-to-project decision, depending on the requirements.

In some cases, the customer may want a new "applet" or feature within a couple of days in a unit with remote update capability. They may want to show off a "cool feature" on a fair.

In some cases, the code may be expected to run unchanged for many years in multi-k products which would require transport to factory if they contain a major error.

In some cases it is ok to switch to a $100 more expensive processor since the end product may cost $10k will all external hardware, making the processor price insignificant.

The point is that '51 code should be efficient.

Why?

If I have a 9600 baud serial port, it doesn't matter if the code is capable of handling 20k characters/second.

If I need to read a voltage every second, it doesn't matter if the ISR is able to process 8k samples/second or not.

If the application fits in available memory, it doesn't matter if there is 1kB or 10kB code space free.

Only if the application hits (or may hit) a limit is it meaningful to make a decision if it is better to try to squeeze/speed up the code, or switch to faster/larger iron.

The main thing is to write correct code that is also easy to maintain. The need for optimization is more a project-to-project decision, depending on the requirements.

In some cases, the customer may want a new "applet" or feature within a couple of days in a unit with remote update capability. They may want to show off a "cool feature" on a fair.

In some cases, the code may be expected to run unchanged for many years in multi-k products which would require transport to factory if they contain a major error.

In some cases it is ok to switch to a $100 more expensive processor since the end product may cost $10k will all external hardware, making the processor price insignificant.

The point is that '51 code should be efficient.

Why?

If I have a 9600 baud serial port, it doesn't matter if the code is capable of handling 20k characters/second.

If I need to read a voltage every second, it doesn't matter if the ISR is able to process 8k samples/second or not.

If the application fits in available memory, it doesn't matter if there is 1kB or 10kB code space free.

all the above is (partially) correct; however applying such thinking will, very likely, hit you in a large muscle when the next feature is to be added for MKII of your product.

Also, if you habitually code efficient, you will not have to 'fight' when a project comes up that absolutely require efficient coding.

In some cases it is ok to switch to a $100 more expensive processor since the end product may cost $10k will all external hardware, making the processor price insignificant.
Absolutely, I have always stated "use the right processor for the job, do not try to make the '51 an 'universal' solution".

Erik