Opened 8 years ago
Last modified 8 years ago
#4045 new enhancement
[PATCH] CmpRangeManager optimisation
Reported by: | wraitii | Owned by: | |
---|---|---|---|
Priority: | Nice to Have | Milestone: | Backlog |
Component: | Core engine | Keywords: | patch |
Cc: | Patch: |
Description
Following some recent profiling, I have noticed that a big part of PerformQuery is checking each entity for the existence of a given interface in TestEntity.
The attached patch is rather barebones, but stores a pointer to the component cache in the entity data and thus makes this computation much much faster.
Would like some other people to confirm or infirm the results. I personally tested over an MP replay.
NB: fairly sure 64-bit systems will need the struct size to be 36 and not 32, should have used 28 + sizeof(void*).
Attachments (4)
Change History (8)
by , 8 years ago
Attachment: | CCmpRangeManager.cpp.patch added |
---|
comment:1 by , 8 years ago
by , 8 years ago
Attachment: | fewercopy.patch added |
---|
comment:2 by , 8 years ago
fewercopy.patch changes the way we iterate the subdivision query results. Instead of copying the subdivision vectors in a larger vector, we copy a pointer to the first member of that vector and a size. Then we iterate in two steps, first over the returned vectors, then over the size (recasting everything properly). Data locality should be pretty good still.
This should be a bigger optimization if there are many entities in subdivisions.
Additionally hadn't noticed but we could probably skip the "empty" verification, since size would be 0.
by , 8 years ago
Attachment: | fewercopy.2.patch added |
---|
Updated to remove the empty check and the misplaced auto
by , 8 years ago
Attachment: | fewercopy.3.patch added |
---|
Saner version passing a vector thanks to sanderd
comment:3 by , 8 years ago
Keywords: | review removed |
---|
See comments in irc (http://irclogs.wildfiregames.com/2016-06-14-QuakeNet-%230ad-dev.log)
comment:4 by , 8 years ago
Milestone: | Alpha 21 → Backlog |
---|
Only one comment I think:
17:12 <@leper> #4045 not sure I like all that leaking of internal data structures all over the place
In 18344: