Even consolidating multiple jobs "haul goblinite armor from square A to stockpile B" would be a big improvement, and is simpler than checking proximity. This would also give us a workaround: Make a quantum dump in the middle of goblinite, dump everything, and then reclaim, so it gets hauled to stockpiles efficiently. There wouldn't be a need to create "haul many items" type jobs in job list, as long as Dwarf could TSK many jobs at once (but this approach is probably suboptimal).
I'd also like to see an improvement to stockpiles: one pointer for taking items from another stockpile and one for giving to another stockpile. While not a true n:m relationship, it would still be more versatile than the current system, where a stockpile can be given items by many stockpiles, but one stockpile can give items to only one stockpile. With my suggestion giving and taking are functionally similar, but distinct. Any stockpile could give items to one stockpile and take items from one stockpile. That way you could have 1:n and n:1 in various combinations, and m:n would require a "relay" stockpile in the middle (m:n could be formed by m:1 and 1:n). It would ofc require coding various borderline cases (Can stockpile A take from B, while B gives to A? etc)
On Floodfill: you can do it only once for point A, and list enough items to fill wheelbarrow, and even do it as a breadth-first search, but ONLY PROVIDED you have information on items stored in tiles. AFAIK, tile doesn't know, what items are there, it it items, that know where they are. A pretty good way to quickly access information about nearby items would be to use Z-addresses. A Z-address is in short an integer generated from coordinates in such a way, that nearby Z-addresses usually mean that items are close, and for any given distance from initial point you can calculate minimum and maximum Z-addresses worth looking at. This property plus indexing points in space by their Z-addresses greatly speeds up dbscan clustering algorithm (from O(n^2) to O(eps*n^2 + n*log(n))).
http://en.wikipedia.org/wiki/Z-order_%28curve%29http://en.wikipedia.org/wiki/UB-treehttp://en.wikipedia.org/wiki/Quadtree NW Kohaku, please clarify, weather you want to optimize FPS time or Dwarf walking time.
As for wheelbarrows, I see them as backpacks / bins on wheels, and anything in them weights less for the purpose of carrying speed.
If Dwarf could store items in wheelbarrow driven by another dwarf, it could lead to rather amusing spam of "hauler cancels store item in wheelbarrow, wheelbarrow misplaced", and other bugs
I remember another suggestion about improved hauling: workshops having miniature input stockpiles, that generate hauling jobs for materials for queued items, so crafters don't need to go themselves to nearby quantum dumps. Do the same for building walls.
I have another suggestion about improving proximity(A) to B type hauling: Mass melting. Melting would be more efficient if multiple items
made of the same material were hauled to smelter before actual smelting. It seems more realistic to collect a whole batch of scrap metal before smelting, than burn all that coal to melt 1 bolt or cup or something, and get almost nothing from it.