This is a very different solution to the current perceived pathfinding slowdown. Please don't bother bringing up other techniques that have been discussed before. To understand this you should have a basic idea of how A* works; if you don't have that knowledge please get it before commenting.
Throughout this post I will use XD, YD, ZD for where the dwarf is; X, Y, Z for the target object location; and XW, YW, ZW for where that object needs to go.
The basic premise is that most jobs currently use a Pythagorian calcluation on the Cartesian coordinates to determine which object to use. This involves looping through all objects, calculating the 'distance' for each that is applicable to the job. Then targetting the location of the one found to be 'closest' for pathfinding. The 'distance' above results in a single precise calculation for the initial H factor in the A* alogarithm. That number then is recalculated with each step to determine if movement was in the correct direction.
The first question is always, "Should we calculate a path?" This seems to already be handled in a very quick fashion for all types of jobs. Perhaps it could be made faster, but it is very difficult to guess. I will skip past this question.
The next question is, "Where should the path go?" In the case of a workshop job it needs to go to the object closest to the workshop. A dumping job has mostly the same answer, we want an appropiate object closest to the dump site. The answer to which object is closest can only be accurately calculated by pathing, an obvious conundrum.
In order to solve this catch22, sort the objects based on the Z axis as they are checked for appropiateness. Then compute the 'distance' only for those that have a Z=ZW. If this results in no values being computed then the pathing will have an H factor of MAXINT initially. I will also suggest that the 'distance' calculation be simplified at this step. The simple form used is D=abs(X-XW)+abs(Y-YW), then the lowest value calculated is used as the H.
With an initial H value decided we can begin pathing. Each step of the path should check for 2 things.
1: We are at an appropiate object. By indexing the start and end points in the Z sorted list of objects the testing loop can be kept small. To make the looping even smaller it only needs to be checked when the H factor of the destination tile is 0. The H value for each step in the path would be the previous tile's H minus 1 (2 when the step was a diagonal). If the H goes negative or reaches 0 then the tile is checked for a match. If an object isn't there then 'distances' are computed based on that location and the correct H is set for that tile.
2: We have reached a stair/ramp. When this occurs it is time to compute more 'distances'. In this case we are looking at the Z level that is being led to, and calculating an H value for the outlet of the stair/ramp based on objects in that level. The list of objects is already sorted, and we have an index that is 1 away from anything on that level. If the calculated H for objects on the new Z level is less than the H of our current stair tile then we put that calculated H+1 at our stair location. This will result in the up/down step having the correct H.
Let's take a moment to consider the obvious implications of this change to the alogarithm. The A* method uses the H factor to determine if it is searching in the correct direction. So far the change is completely breaking that, and making the path calculation more of a flood fill method. When we consider that most fortress layouts already cause the H value of A* to work against us this doesn't seem like a bad thing.
The result we have so far is a path from XW, YW, ZW to the object X, Y, Z. We actually need a path from XD, YD, ZD to X, Y, Z and a path from X, Y, Z to XW, YW, ZW. The second path is just a matter of reversing all the directions in the path we currently have. The first path is no longer looking for an object it is looking for a specific location and might need to be calculated.
We have to return to that first question, "Should we calculate a path?" The reason to ask this again is because the dwarf might already be at the workshop. This would mean we have a perfect path already. If that is the case the workload has been cut by more than half.
Assuming it is not the case we are back to calculating a path. The second question, "Where should the path go," seems to be answered; in reality it isn't answered. We already computed a path to the object, and it is very likely that some portion of that path will be valid for this new path. The object we are trying to path to in this case is a point in our existing path. We can use the exact same alogarithm described above by looking at the locations that first path went through as possible destinations. Once the new path connects with the one we already have determined, the 2 paths can be assembled into a single one.
Next we need to look at what happens when the dwarf decides to get a drink in the middle of the job. They aren't cancelling the job. It makes the most sense to keep the path from the object to the workshop, and keep that object tasked to the job. This does present a problem for things that can rot. In order to handle this the object's original location should be kept available until the object has been changed and multiple taskings should be able to be set on each object. When the cook drops something in the middle of bringing it to a kitchen it would be tasked to be brought back to the stockpile and tasked to be cooked in the kitchen. The return to stockpile would be putting it back exactly where it was and would use the part of the path to the kitchen that the object had travelled. The cook returning to duty before the object made it back to the stockpile would cancel the return job and could then path to the point the object is dropped at, and we would already have path from that point to the kitchen.
We should also look at some other types of things dwarfs like to walk to.
Mining, detailing, and woodcutting are the first to come to mind. Here the object we use is the designation, and the workshop location is actually the dwarf. This eliminates the top-left scanning currently used with these jobs. The path is always computed based on what is closest to the dwarf.
Another one to examine is getting a drink. The objects in this case are available barrels containing drinks. Again we find that the change in method is an improvement in dwarven intelligence.
The real question is does this method make anything faster. To answer that we have to compare what is already being done with the changed alogarithm.
1: Accumulating a list of viable targets. Done in both.
2: Calculating 'distances' to targets. Done once in A* for all targets. Done repeatedly as needed in the new method; which could be slower. Reduction of precision in the new method and restricting calculations by Z should result in speed equality.
3: Examining tiles in the wrong direction. This can occur with both methods because of layouts. I can't determine any clear difference in quality on this point.
4: Walking past a viable object. A* does this all the time because of the 'distance' calculation determining a fixed destination. The object based method changes the destination as needed to home in on what is closest. This should frequently result in shorter paths.
I believe that last statement is what will result in faster pathfinding while improving dwarven intelligence.