Yes, I'm familiar with this kind of optimization. Some years ago I wrote I program to calculate the flight path of objects through our solar system. Compared to the numbers from this old projects, MPGuino numbers are peanuts
I already rearranged some of the calculations, but basicaly it's one of the points that will be done in future versions of my projects..
But you have to be careful, I think your example can't work this way:
x = ( 3,600,000,000 / (parm[uSperGallon] * (instInjEnd - instInjStart)) ) /* does not overflow */
parm[uSperGallon] * (instInjEnd - instInjStart) will be very big:
115384616 * (instInjEnd - instInjStart), where the result of (instInjEnd - instInjStart) may be anything between 0 and 500. Basically, here is the first mistake in MPGuino code: It's trying to divide by 0 if the cars has overrun fuel cutoff!! If you compile this and run it, some versions of the AVR toolchain will create wired numbers on your display, others show 0.
Back to toppic, lets assume 500 for the result. Then:
115384616 * 500 = 57692308000. This doesn't fit in an unsigned long. Even if you reduce 500, the division of (3,600,000,000 / result) will lead to 0, which crashes the rest of your calculation and if not, it will be very unprecise.