Checking out the generated javascript, the following matched an inefficient pattern of: Math.min(Math.floor((($foo$0 >>> 0) + ($foo$1 | 0) * 4294967296 - (($bar$0 >>> 0) + ($bar$1 | 0) * 4294967296)) / 4294967296), 4294967295); =============================================================== uFloat.most-of-the-class Extensive QWordValue math - would need rewriting to use Frac/Round uGearsUtils.CalcRotationDirAngle QWordValue used for abs math for float conversion. Unlike other uses, precision does not matter that much (visual value only, range of 0-360, accuracy below integer level not really that important). uGears.doStepFallingGear QWordValue used for abs math. multiple instances uGears.doStepRopeWork QWordValue used for abs math. one instance. uGears.doStepPortal and ((iterator^.dX.QWordValue + iterator^.dY.QWordValue) < _0_08.QWordValue) seems to be the only one. unfortunately called quite a lot w/ an active portal. RCPlane stuff appears fine? (obviously not called often anyway) uGearsHedgehog.doStepHedgehogMoving QWordValue used for abs math. multiple instances. uLand.GenMap int_64t in math throughout. they all look safe uLandObjects.AddObjects int_64t in adding girder - unneeded because if playing area gets that big, we'll be out of memory uVisualGears.doStepFlake int_64t in flake position check - unneeded uVisualGears.doStepTeamHealthSorter int_64t in health bar width - unneeded =============================================================== [In order of performance impact] uFloat rewriting this should help quite a lot. My experiment w/ subtraction operator revealed a bit of a gain, although llvm used the emulated _llvm_uadd_with_overflow_i32 which it would be nice to massage it into not doing. Hand optimising this to eliminate that yielded a bit more of a gain. clang has no way to control optimisation w/ a pragma like gcc has. uGears.doStepFallingGear Called a lot. Unfortunately the gtGenericFaller does not help matters uGearsUtils.CalcRotationDirAngle Called in every spinning gear uGearsHedgehog.doStepHedgehogMoving uGears.doStepPortal when portal is active, appears this one could get hit a lot. unfortunately the compiled code calculates the inefficient pattern before running the test. Moving this condition to an inner test might be sufficient to avoid most of the hit. All the int64_t stuff, while important, I think could be removed. They all seem unneeded and easily fixed. For uFloat, something like the following would be needed, everywhere. Rewrite: ==================================================================== operator - (const z1, z2: hwFloat) z : hwFloat; begin if z1.isNegative = z2.isNegative then if z1.QWordValue > z2.QWordValue then begin z.isNegative:= z1.isNegative; z.QWordValue:= z1.QWordValue - z2.QWordValue end else begin z.isNegative:= not z2.isNegative; z.QWordValue:= z2.QWordValue - z1.QWordValue end else begin z.isNegative:= z1.isNegative; z.QWordValue:= z1.QWordValue + z2.QWordValue end end; ==================================================================== To: ==================================================================== operator - (const z1, z2: hwFloat) z : hwFloat; begin z:= _0; if z1.isNegative = z2.isNegative then // if z1.QWordValue > z2.QWordValue then if (z1.Round > z2.Round) or ((z1.Round = z2.Round) and (z1.Frac > z2.Frac)) then begin z.isNegative:= z1.isNegative; // z.QWordValue:= z1.QWordValue - z2.QWordValue z.Round:= z1.Round - z2.Round; z.Frac:= z1.Frac-z2.Frac; if z2.Frac > z1.Frac then dec(z.Round) end else begin z.isNegative:= not z2.isNegative; // z.QWordValue:= z2.QWordValue - z1.QWordValue z.Round:= z2.Round - z1.Round; z.Frac:= z2.Frac-z1.Frac; if z2.Frac < z1.Frac then dec(z.Round) end else begin z.isNegative:= z1.isNegative; // z.QWordValue:= z1.QWordValue + z2.QWordValue z.Round:= z1.Round + z2.Round; z.Frac:= z1.Frac + z2.Frac; if z.Frac