Hey all,
As you've undoubtedly noticed ever since JD CK2+ has been much slower and now is once again back to old form in terms of speed. All of this can be boiled down to one specific issue: Huge complexity in only the Silk Road.
What took so long to notice?
This is a simple question to answer. We were looking at too broad of a stroke of a reason what was causing the slowdowns. We looked at events in-general, trade in-general and so on. It wasn't until recently that we tried to pick apart things at a more granular level. It was there that we identified that only the Silk Road was causing a very large uptick in performance cost.
Why only the Silk Road?
A screen shot of before and after will help illustrate my example.
Fig. 1 Before and After
As you can see in Fig. 1, there are less sub-parts of the silk road in the Middle East. That by itself however wouldn't actually be good enough; In fact that specific point does not have much of an impact by itself on the performance. What was a bigger issue are parts that feed into other parts increasing the code complexity of the route. So what I did was trim the fat.
Does route Homs -> Antioch need to exist, if both Homs and Antioch already have paths connecting them? While this part of the Silk Road certainly existed historically, it also added a footprint on the performance. Each one of these footprints seems to have exponentially increased the cost for each iteration of such a path in the chain, leading to the performance loss we had.
Don't other trade routes have this issue?
It is true that other trade routes in the mod have similar issues however the big difference is that they have far less of them total. In a future build a few of these will also be snipped in other routes to gain some marginal speed improvements and to allow the silk road to gain a few more paths as a trade off.
Fig. 2
As you can see in this fig. 2 once we started to compare other routes it became obviously clear that while other routes caused a speed loss that was deemed acceptable, the Silk Road itself was the main culprit in the speed loss.
Why was this only a problem with JD?
Previously routes were binary, they were on or off, with no gradients. As such I had designed those routes with many side paths that feed into each other so that only sections would ever be turned off unless several key points were strangled.
With JD however trade routes became much more fluid, where-in partial blockages could happen. This is a much better system design wise but clashed heavily with our old design assumptions. Now all those side routes and such that were previously needed became a huge burden onto the engine.
Trade Routes Moving Forward
In the future there likely be various, albeit smaller, adjustments to the trade routes now that we better understand the performance impact specific adjustments can have on the engine. It is unlikely that we will be adding much, if any, joined sections of routes opting instead for more 'dead ends'. That doesn't mean that loops won't exist, just that they'll be avoided
Cheers and Happy Gaming,
- Z
As you've undoubtedly noticed ever since JD CK2+ has been much slower and now is once again back to old form in terms of speed. All of this can be boiled down to one specific issue: Huge complexity in only the Silk Road.
What took so long to notice?
This is a simple question to answer. We were looking at too broad of a stroke of a reason what was causing the slowdowns. We looked at events in-general, trade in-general and so on. It wasn't until recently that we tried to pick apart things at a more granular level. It was there that we identified that only the Silk Road was causing a very large uptick in performance cost.
Why only the Silk Road?
A screen shot of before and after will help illustrate my example.
Fig. 1 Before and After
As you can see in Fig. 1, there are less sub-parts of the silk road in the Middle East. That by itself however wouldn't actually be good enough; In fact that specific point does not have much of an impact by itself on the performance. What was a bigger issue are parts that feed into other parts increasing the code complexity of the route. So what I did was trim the fat.
Does route Homs -> Antioch need to exist, if both Homs and Antioch already have paths connecting them? While this part of the Silk Road certainly existed historically, it also added a footprint on the performance. Each one of these footprints seems to have exponentially increased the cost for each iteration of such a path in the chain, leading to the performance loss we had.
Don't other trade routes have this issue?
It is true that other trade routes in the mod have similar issues however the big difference is that they have far less of them total. In a future build a few of these will also be snipped in other routes to gain some marginal speed improvements and to allow the silk road to gain a few more paths as a trade off.
Fig. 2
As you can see in this fig. 2 once we started to compare other routes it became obviously clear that while other routes caused a speed loss that was deemed acceptable, the Silk Road itself was the main culprit in the speed loss.
Why was this only a problem with JD?
Previously routes were binary, they were on or off, with no gradients. As such I had designed those routes with many side paths that feed into each other so that only sections would ever be turned off unless several key points were strangled.
With JD however trade routes became much more fluid, where-in partial blockages could happen. This is a much better system design wise but clashed heavily with our old design assumptions. Now all those side routes and such that were previously needed became a huge burden onto the engine.
Trade Routes Moving Forward
In the future there likely be various, albeit smaller, adjustments to the trade routes now that we better understand the performance impact specific adjustments can have on the engine. It is unlikely that we will be adding much, if any, joined sections of routes opting instead for more 'dead ends'. That doesn't mean that loops won't exist, just that they'll be avoided
Cheers and Happy Gaming,
- Z
