This afternoon I saw this on my server, in which the ygopro process ate up 46GB of my server memory, and an entire CPU core. After investigation, it was caused by those 2 functions checking large groups recursively.
Currently the function is only checked after the whole recursive process. So when the group grows, like Chain Material or Future Fusion, the function would be checked the number equal to card count! times. This would ruin servers for eating up all memories, and result in server crash.
https://github.com/Fluorohydride/ygopro-scripts/commit/742d610b33ab8192a02f1e877dd06569f0962cee is an improvement of this problem. However an ultimate solution to this is, to add a checking function in the middle of the recursive check. (See https://github.com/Fluorohydride/ygopro-scripts/pull/1123, but incomplete) This would cut down large useless recursive checks and improve the performance of the recursive subgroup check a lot.
Any other solutions?
This afternoon I saw this on my server, in which the ygopro process ate up 46GB of my server memory, and an entire CPU core. After investigation, it was caused by those 2 functions checking large groups recursively. Currently the function is only checked after the whole recursive process. So when the group grows, like Chain Material or Future Fusion, the function would be checked the number equal to
card count!
times. This would ruin servers for eating up all memories, and result in server crash. https://github.com/Fluorohydride/ygopro-scripts/commit/742d610b33ab8192a02f1e877dd06569f0962cee is an improvement of this problem. However an ultimate solution to this is, to add a checking function in the middle of the recursive check. (See https://github.com/Fluorohydride/ygopro-scripts/pull/1123, but incomplete) This would cut down large useless recursive checks and improve the performance of the recursive subgroup check a lot. Any other solutions?