[1.3][SSP] Turtles slow down over time

I am playing creative on Tekkit single player.

As part of a much larger project I need to clear huge amounts of space to near bedrock. At the moment I am using 21 turtles running the same program with different arguments to clear the space. The turtles mine each mine a layer 3 high in a square spiral then drop their goods into the center pillar, where it falls down to a transponder and is carried by pipes to the cloud layer for later use. (the blocks are not just laying around: they are successfully put into a chest)

http://www.flickr.co...N07/8109007704/ (this is an image: it will not let me embed Flickr images?)
(the quarry is between 35 and 40 blocks square in this picture)

Initially, everything goes fine, and the turtles tear through the earth at good speed. But after several minutes, they noticeably slow down. I call os.sleep() in my loops, and adjusting their values doesnt seem to change anything. Currently, they only dig/move every 3-5 seconds, and it seems to be slowing down even more. I have a good computer with nothing else running, but start to get lag spikes contemporaneous with the turtles slow-down.

Below is my code. Be forewarned, I used magic numbers and else-wise coded sloppy, but it should be just barely legible. t is the familiar turtle API, but renamed for my convenience. m is the magic API found here: http://www.computerc...ng-exploration/

function fwd()
while false == m.forward() do
  m.dig()
  os.sleep(0.01)
end
end
function dump()
m.faceNorth()
for i=1,9 do
  turtle.select(i)
  turtle.drop()
end
turtle.select(1)
end
function position()
x,y,z = m.getPos()
f = m.getFacing()
end
m.setPos(0,132,0)
m.setNorth()
local args = { ... }
level = args[1]
for i=1,132-(6+level*3) do
while not m.down() do os.sleep(0.1) end
end
m.goToPos(0,6 + level*3,0)
m.faceSouth()
fwd()
m.turnLeft()
fwd()
m.dig()
fwd()
m.turnLeft()

for i=1,3 do
m.digUp()
m.digDown()
m.dig()
fwd()
end
m.turnLeft()
d = 4
sides = 0
while true do
for i = 1,d do
  m.dig()
  m.digDown()
  while t.detectUp() do
   m.digUp()
   os.sleep(0.4)
  end
  position()
  if 0 < turtle.getItemCount(9) then
   m.pathfind(0,y,0)
   m.faceNorth()
   dump()
   m.pathfind(x,y,z)
   m.faceSet(f)
  end
  fwd()
end
m.turnLeft()
sides = sides + 1
if sides % 2 == 0 then
  d = d + 1
end
end

To recreate it exactly, it would probably be easier/best if you made the pillar by hand. It is in this shape, where top of the screen is north:

oCT
CoC
ooo

Where o is air, C is cobblestone, and T is the tube leading up. At the top is simply a energy condenser turning everything into pedestals (highest EMC stack-able item). The pillar tops off at 132, just above the top of the clouds. The transposer is at 5, while the lowest turtle is at 6. Note that because of a miscalculation, this means that the transposer tube's must be at 4, which could be bedrock. (I play on creative, so there is no issue here)

Turtles are placed facing north at the center of level 132 of the pillar, and have the below code called with an argument telling them which layer they will be on. Valid layers are on the interval [0,41].

—

I have a hunch that somehow m.pathfind(), or one of the associated mapping functions, is borked. I haven't looked into it yet, but the documentation said it used A*. Searching a max of 75-80 blocks deep, with almost no branching, with A* should be a trivial task, even if run a maximum of 20 times a second (the turtles have to dump their items far less frequently). This leaves some other problem with the scaling of the MagicTurtle movement API, or a flaw/feature in ComputerCraft.

Regardless, in the near future I will be cutting out the MagicTurtle API and replacing it with one of my own creation that will better serve my purposes.

EDIT: Oh god, it stripped most of my code's whitespace. I will fix that this evening, I have to go now.

Put some debug prints using os.time() to find out how long the path finding operation is taking. I doubt it is the turtles or java code - many turtles work fine together. You really should have tried to find out if the speed loss was down to path finding before reporting it as a bug.

Oh, its not like I didn't look at it. Its just that the relevant functions are several hundred lines of undocumented code with ambiguous variables names (tc, xs, xe, ue, and so on), and apparently with more function parameters than is documented. To debug it in earnest would have taken much more time than I had, so I was hoping for an easy fix here.

I have to leave for a few hours again, but I will set it up with 20ish turtles that os.print() the delta time in their inner loop.

EDIT: Though I have not yet gone back to see them in action, I confirmed in just a couple of minutes of running that the loop time doubled… even when they weren't pathfinding. Just moving. I am now looking at the MagicTurtle's mapping abilities as being the culprit. When I can I will gut the relevant functions and replace them with ones known to be constant-time, just to be sure.