Yes there are cases where small lag adds up, but this isn't one of them.
You're missing the point - I'm saying that all
causes of lag add up. Weather adds lag, temperature adds lag, fluid checks add lag, connectivity checks add lag, status checks add lag, contaminant spread checks add lag, etc. etc. etc.
You can't pretend only the single largest cause of lag matters.
This is especially true when you consider that pathfinding is only usually
the largest cause of lag - the whole point of the Operation FPS Bomb tests were to prove how much item counts alone can add lag to your game. 1,000,000 boulders in the game will crash FPS down to .1 FPS before ever having to pathfind anything.
Causes of lag add up in all
cases, because every algorithm is handled sequentially (there is no parallel processing in DF), so everything is a bottleneck.
Why would it take a tenth of a second per tile? that'd be extremely slow. Memory access is on the order of nanoseconds, not hundred milliseconds. And with tiles in an array, there is a certain amount of pre-fetching and other CPU optimization that makes it so that accessing a lot of tiles is faster per tile than accessing one tile.
It's still only happening only when a tile is mined.
And hundreds of tiles at 5ns a tile is not a significant portion of a second.
You're still ignoring that "just memory fetching a tile" is the exact reason
Pathfinding is so slow.
I'm not kidding when I say "cascade" testing support stresses from all the items at the top of the map downward is basically the exact same formula as pathfinding from every tile on the map. (Except that it would be an inverse formula - pathfinding increases in complexity exponentially the more open space you dig, while support stresses would increase in complexity the more walls you have.)
Jeoshua's calculations aren't quite correct. For starters, it's 48x48 tiles per embark tile, but standard maps will have something like 192x192 tiles plus at least 100 z-levels, adding up to around 4 million tiles.
5 nanoseconds is also an underestimation of memory fetch times in most cases - CAS latencies will usually be more in the range of 7-15 ns per fetch request. And that's only for the first word read.
You will have to sequentially access data from essentially every tile on the map, which takes almost a million of memory fetches on larger maps, and a million of memory fetches at "just a few nanoseconds per tile" of 10 nanoseconds adds up to 10 seconds. Per tile you mine. PLUS
you haven't even started pathfinding or doing fluid motion checks or anything else that adds all the lag we have in the game already.
Finding an exact number for typical memory access time isn't trivial. A processor has several stages of caches, The cost of a cache miss is about 10 times longer for each one, with access to memory being the longest. However, memory is fetched in batches, so successive accesses after the first byte are much faster. The data rate for memory is the bottle neck in for the successive calls. Then you have to estimate the cache miss rate.
Top of the line RAM has peak access time of 0.23 ns per Word. Finding an number for cache miss time is harder, as it's not so readily advertised.
Caches don't matter. Not when you're loading several megs of data, you're not going to cache that - you have to load from RAM, because the computer is not going to be able to properly anticipate where the next RAM load is, and you're going to have to wait on a full RAM fetch. That's why pathfinding takes so long, because it's the exact same thing.