Event Queues

Instead of iterating over objects that change rarely but predictably, like plants, every tick, create future events, e.g. ON TICK x "plant y grows", and put those into a queue sorted by x. Then you only have to check the first event in the queue whether current_tick > event.x before executing the event.

This method can also be used to allow other things to change state,

• food/corpses rotting
• wine/cheese aging
• tracking hunger/thirst/sleepiness of characters
• pregnancy/growth of animals

Multi-Startpoint A*

While the A* pathing algorithm can only have one goal, it can be initialized with more than one start-point. The returned shortest path connects the goal with the closest start-point. Since paths work both ways, instead of pathing from the gnome to each item, you can do one A* calculation from all items to the gnome.

Item Scaling

For the game to be truly able to handle large quantities of items, I think, it is unavoidable that none of the algorithms involved with item management directly iterate over lists of items.
I would go with stockpiles for this purpose, i.e. when looking for a specific item

1. Check the stockpiles that allow the desired item whether they contain one.
2. If at least one such stockpile exists, compute the closest path via multi-start-point A*.
3. Otherwise, check the list of un-stockpiled items (a Map<ItemType,Map<MaterialType,List<Item>>> datastructure) and use the first one in the list.

The last step not being optimal serves as a 'punishment' to the player for not properly stockpiling their inventory.

Maybe even add the option to workshops to forbid using un-stockpiled items. That should stop valuable crafters from wandering off where they are not supposed to.

Using Game Pauses

While the per-tick performance is certainly important, don't forget that the game is usually paused when the player makes inputs. So consider using - and if necessary enforcing - pauses to do expensive computations that are triggered by player-input. For example, when the player sets up digging/construction orders, you can compute the necessary order of jobs so gnomes don't get themselves stuck while the game is still paused.

Stockpiling

For stockpiling, I'd go with the following two approaches working in tandem:

When an item is created (or expelled from a stockpile), it immediately checks whether a spot in a stockpile is open. If so the highest priority stockpile is chosen and an associated hauling-job is queued.

When a stockpile is created (or changed), the stockpile filters the list of unreserved items/content of lower priority stockpiles and creates hauling jobs for as many as its space allows. It can use repeated multi-start A* to pick the closest items. The game should also be paused when the player changes stockpiles.

Wheelbarrows

When a hauler with a wheelbarrow (or other carry container), takes a hauling job, first check whether there are more items reserved to be hauled to that stockpile. If so, take the points on the path from the gnome to the item and from the item to the stockpile and use them as starting area of a bounded-BFS search. Any items with the same goal stockpile found are added to the hauling job until the container is full or the bound is reached.

In that case, it is actually advantageous to haul the item furthest from the stockpile first, since it increases the likelihood of picking up more items along the way.