When trying to manually set rotation angles in the cube demo you have to calculate both cos & sin for the X rotation & again for the Y rotation. There were a few more optimizations to be had in eliminating division branches & combining the unsigned projection tables into 1 signed table.  To increase the chance of the gears having enough resolution, the trig tables were increased to 256 entries with a range from -127 to 127.

The fastest way to draw a gear is going to be procedurally drawing 1 side of a gear with the Z rotation applied, then drawing 1 point on the other side to calculate a fixed offset between the 2 sides, then applying XY rotation with the existing code.  Add the fixed offset to the one side to create the other side.

The cube demo can similarly be optimized by only computing 4 points & using those 4 points to compute fixed offsets to create the other 4 points.  Technically a 4x4 transformation matrix does the same thing as adding a fixed offset to every point, but it also has a scaling step which is slow.  

The gears would be baked in polar coordinates at compile time, then rotated & converted to XY coordinates for each frame.  A key optimization would be precalculating the polar to XY conversions for the 9 circles in the model.  That would use 512 * 9 or 4608 bytes.  By knowing cos is just sin with a phase offset of 64, this can be reduced to 320 bytes per circle or 2880 bytes.

The thought occurred of how fast glxgears would run on an arduino if it used the same methods, but the point of that demo was manely to show the REGIS protocol drawing over a serial port.

The original cube demo hard coded which coordinates to use for all the line drawing commands.  A more general gear routine needs to convert a batch of polar coordinates into 2D points.  Another routine needs to draw lines from the set of points.  The biggest gear contains 200 points.