micro optimization #6
No reviewers
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
IllusionMods/BetterPenetration!6
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "small-optimization"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The following two points have been changed.
Please review and merge.
Add code to call PostBuild.bat in the post-build script
Reduce GCAlloc
The profiler showed it was a problem, so I did some micro-optimization of the code.
At first I thought it was the O(N^2) code using RemoveAt, but it seemed to be caused by GCAlloc due to the reference to .name.
Changes in loading time for huge scenes:
Before, average: 36.84
After, average: 34.76 -2.08
Before profile:

MonoProfilerOutput_2024-08-25_13-23-16.csv
After profile:

MonoProfilerOutput_2024-08-26_17-31-48.csv
Memo:
There are 20 characters in this scene. The 1120 calls to RemoveCollidersFromCoordinate(ChaControl) seem excessive.
Memo2:
ExtensibleSaveFormat.ExtendedSave/Hooks: I tried to reduce the GCAlloc of ChaFileLoadFileHook because it was large, but it actually got slower.
I suppressed the generation of huge byte arrays using ReadBytes(), and
changed MessagePackSerializer.Deserialize@byte[] to MessagePackSerializer.Deserialize@Stream.
The execution time of ChaFileLoadFileHook alone was reduced from 500ms to 1.5ms. This was great, but the total execution time, including children, increased from 3s to 5s, and GCAlloc increased from 300MB to 3.6GB.
It seems that deserializing from a stream is quite heavy.
Before source code:
After source code:
before:

after:

I'll try to see if I can group the calls to the same character in the same frame.It probably won't be as sensitive as the coordination.
I don't know the extent of the impact, so I'll stop for now.
That RemoveRange trick is nice, I'll be using that myself.
The Deserialize@Stream change is surprising, I would have guessed it would be faster. There's probably some sort of side effect of reading that stream that causes issues down the line with how the stream is cached.
This might work differently between games, especially KK and KKS, because of differences in mono and framework versions.