Fuel Slowdown Fix

We believe that we have made a breakthrough on the fuel slowdown issue.

While running the automated tests, we recorded which methods from the fuel interface were being called. From this information, we created a new automated test that only calls these methods from the fuel interface in the same order as they are called during the normal test.

The result was a way to reproduce a memory increase. This was fantastic news, as it gave us a way to investigate what was going on.

During this test we found the method that was causing the memory build-up. The interesting thing is that when this method was called in an infinite loop, the memory would skyrocket. But when it was called with a 100ms sleep in between, the memory would stay the same.

What we found out was that the string returned to us from the fuel interface was allocated as a system string. This string gets freed by the system when the system is ready. However, when this method is called lots in a row (like the infinite loop), it would not get a chance to do this.

So what we tried was to explicitly tell the interface that we have finished with the string. We did this by using the SysFreeString method. Then, we ran the ‘infinite loop’ test, and the memory stayed the same. We then ran the fuel interface test, and then the regular stress test, and the memory stayed the same. Even on the trouble machine.

I suspect that on the other machines, the system had a chance to free the system strings. But on the machine that was causing the issues, the system did not have that chance. Since these were system strings, this could explain why the system was slow even when Amicus was closed.