Improved Pathfinder Debugging

[VictorPhilipp]

• Path-find logging is batched
• switch 26 toggles whether only failed path-finds should be logged

[krzychu124]

Testing...

[krzychu124]

I think you forgot to change Global config version number because I'm getting Array index is out of range 😉

[krzychu124]

First, I am not sure how it supposed to work.

I thought that after that little change we will see only log with list of unreachable segments with pathfinding history stack but I can see that I was wrong 😄

• ~15min game running and TMPE.log has 22m lines which takes ~0.6GB of disk space
  Do you have some sort of processing tool to cut out useful info, because it seems that is too much data to do that manually with just scrolling and searching tool or I just don't have 'that' skill yet 😅

String.Formatis killing performance of logging, that's for sure, but I am sure you know that and I think that performance gain of logging wasn't the main intention of this PR 😉

[VictorPhilipp]

I have not raised the version because extending the Debug class does not affect regular users. Should I increase it nevertheless?

First, I am not sure how it supposed to work.

The synchronization code in Log._Debug adds a siginificant overhead that I wanted to avoid. That's why I make it accumulate log entries until path-finding is complete. Then, I decide (based on the outcome of path-finding and based on Switches[26]) whether to save the accumulated entries to the log file in one single batch. Use case: In order to investigate on #361 I wanted to know why taxi path-finds failed. Now, with Switches[26] we can now decide to only log failed path-finds.

* ~15min game running and TMPE.log has 22m lines which takes ~0.6GB of disk space
  Do you have some sort of processing tool to cut out useful info, because it seems that is too much data to do that manually with just scrolling and searching tool or I just don't have 'that' skill yet 😅

Well, I do it manually indeed. I choose a segment in-game and check whether path-finding ever considered this segment.

It would be really nice to have a visual in-game path-find debugger!

String.Formatis killing performance of logging, that's for sure, but I am sure you know that and I think that performance gain of logging wasn't the main intention of this PR 😉

I thought that String.Format uses a StringBuilder internally? I expect it to have a certain overhead but it should not be a performance killer? Lighten me up! :-)

[krzychu124]

I will check if version change is necessary because I remember that I changed switch[0] to true in xml config but forgot to add new one for log failed path-finds only.

I thought that String.Format uses a StringBuilder internally? I expect it to have a certain overhead but it should not be a performance killer? Lighten me up! :-)

Yeah, you were right, String.Format uses StringBuilder internally (just checked source code 😉 )

Visual in-game path-find debugger 😍

[krzychu124]

Yup, it seems that the mod is not seeing that additional flag from Debug class because it was overwritten by deserializer. Line 171 not called to reset Debug instance with new switches.
https://github.com/krzychu124/Cities-Skylines-Traffic-Manager-President-Edition/blob/cda3cd9ebb748fc4922f6a25ae4f68dcd1bd1628/TLM/TLM/State/GlobalConfig.cs#L160-L172

[originalfoo]

Any updates on this? All the other stuff for 10.21 release is close to merge and this looks like it might be a straggler?

[originalfoo]

Just noticed this PR uses switch 26 for pathfinder stuff, however merged PR #513 is now using that switch for speed limits.

This PR #370 will need updating to use switch 27.

[kvakvs]

This might be a great moment to give names to XML values and then the conflict will be gone.

[DaEgi01]

Closing this PR for now, since there was no progress for more than a year.
In case this is still relevant PR can be reopened.