Efficient programming is programming in a manner that, when the program is executed, uses a low amount of overall resources pertaining to computer hardware. A program is designed by a human being, and different human beings may use different algorithms, or sequences of codes, to perform particular tasks. Some algorithms are more hefty and resource-intensive while accomplishing the same task than another algorithm. Practicing to create a low file size and low resource algorithm results in an efficient program.
Gaming is one of the highest-earning markets in the computer and video game console world. Efficiency in gaming machines varies but similar patterns have been seen over the years. In the 1990s during the dawn of what came to be modern-day gaming, computer hardware was much inferior to its current state. Programmers typically had to focus very much on efficiently programming their games so they could run on the hardware. However, hardware's' overall power has increased exponentially throughout the new millennium, and the general need to focus on efficiency has decreased.
Console games are typically programmed more efficiently than PC games because the game are designed and optimized to run on one particular type of machine. On PCs, games must be programmed to work on thousands of hardware combinations. Very often console-coded games are ported over to PCs and therefore run less efficiently. Games that run less efficiently are optimized, and do not use the minimal amount of resources.
Efficiency Over the Years
True efficiency of a particular program is subject to argument, as programs certainly do become more resource-intensive throughout time as computers' power is put to the task of operating heavier data calculations. However, processing power can also be abused and result in a program that is programmed inefficiently. Efficiency varies from program to program, but is often taken into consideration still so a program can run better on an older machine.
In Scratch, optimization is important for larger projects because Scratch is an interpreted language. Compiled machine code that runs on the computer reads other codes or "interprets" them which causes Scratch to be resource-intensive. 3D projects, for example, run at a poor frame rate typically in Scratch because Scratch is not efficient enough or optimized for 3D. Furthermore, in Scratch most of the rendering is done by the processor, which makes it even more CPU-intense.
One common problem that makes projects slow is the use of multiple very similar scripts. Take the following, for example:
when gf clicked forever if <key [right arrow v] pressed?> change x by (10) end when gf clicked forever if <key [left arrow v] pressed?> change x by (-10) end
Rather than using two scripts, it would be much better and faster to combine them into one:
when gf clicked forever if <key [right arrow v] pressed?> change x by (10) end if <key [left arrow v] pressed?> change x by (-10) end
Another common issue that causes scratch projects to slow down is the use of Graphic Effects. The removal of pixelblender support in the flash player makes these blocks very slow.  The effects blocks slow things the most when they are placed in a loop (repeat, forever, etc.) This script, for example, would cause a project to lag (unless being played on a very fast computer):
when gf clicked forever change [color v] effect by (10) endThe one exception to this is the "ghost" effect. While it may slow things down, it does not do so nearly as much as the other effects.