mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-12 10:42:37 +00:00
2b9eba0fe0
* Smoothing groups optimization, save 265ms with configs, more on production & w/ space ruins (#71989) This one is fun. On every /turf/Initialize and /atom/Initialize, we try to set `smoothing_groups` and `canSmoothWith` to a cached list of bitfields. At the type level, these are specified as lists of IDs, which are then `Join`ed in Initialize, and retrieved from the cache (or built from there). The problem is that the cache only misses about 60 times, but the cache hits more than a hundred thousand times. This means we eat the cost of `Join` (which is very very slow, because strings + BYOND), as well as the preliminary `length` checks, for every single atom. Furthermore, as you might remember, if you have any list variable set on a type, it'll create a hidden `(init)` proc to create the list. On turfs, that costs us about 60ms. This PR does a cool trick where we can completely eliminate the `Join` *and* the lists at the cost of a little more work when building the cache. The trick is that we replace the current type definitions with this: ```patch - smoothing_groups = list(SMOOTH_GROUP_TURF_OPEN, SMOOTH_GROUP_FLOOR_ASH) - canSmoothWith = list(SMOOTH_GROUP_FLOOR_ASH, SMOOTH_GROUP_CLOSED_TURFS) + smoothing_groups = SMOOTH_GROUP_TURF_OPEN + SMOOTH_GROUP_FLOOR_ASH + canSmoothWith = SMOOTH_GROUP_FLOOR_ASH + SMOOTH_GROUP_CLOSED_TURFS ``` These defines, instead of being numbers, are now segments of a string, delimited by commas. For instance, if ASH used to be 13, and CLOSED_TURFS used to be 37, this used to equal `list(13, 37)`. Now, it equals `"13,37,"`. Then, when the cache misses, we take that string, and treat it as part of a JSON list, and decode it from there. Meaning: ```java // Starting value "13,37," // We have a trailing comma, so add a dummy value "13,37,0" // Make it an array "[13,37,0]" // Decode list(13, 37, 0) // Chop off the dummy value list(13, 37) // Done! ``` This on its own eliminates 265ms *without space ruins*, with the combined savings of turf/Initialize, atom/Initialize, and the hidden (init) procs that no longer exist. Furthermore, there's some other fun stuff we gain from this approach emergently. We previously had a difference between `S_TURF` and `S_OBJ`. The idea is that if you have any smoothing groups with `S_OBJ`, then you will gain the `SMOOTH_OBJ` bitflag (though note to self, I need to check that the cost of adding this is actually worth it). This is achieved by the fact that `S_OBJ` simply takes the last turf, and adds onto that, meaning that if the biggest value in the sorting groups is greater than that, then we know we're going to be smoothing to objects. This new method provides a limitation here. BYOND has no way of converting a number to a string at compile time, meaning that we can't evaluate `MAX_S_TURF + offset` into a string. Instead, in order to preserve the nice UX, `S_OBJ` now instead opts to make the numbers negative. This means that what used to be something like: ```dm smoothing_groups = list(SMOOTH_GROUP_ALIEN_RESIN, SMOOTH_GROUP_ALIEN_WEEDS) ``` ...which may have been represented as ```dm smoothing_groups = list(15, MAX_S_TURF + 3) ``` ...will now become, at compile time: ```dm smoothing_groups = "15,-3," ``` Except! Because we guarantee smoothing groups are sorted through unit testing, this is actually going to look like: ```dm smoothing_groups = "-3,15," ``` Meaning that we can now check if we're smoothing with objects just by checking if `smoothing_groups[1] == "-"`, as that's the only way that is possible. Neat! Furthermore, though much simpler, what used to be `if (length(smoothing_groups))` (and canSmoothWith) on every single atom/Initialize and turf/Initialize can now be `if (smoothing_groups)`, since empty strings are falsy. `length` is about 15% slower than doing nothing, so in procs as hot as this, this gives some nice gains just on its own. For developers, very little changes. Instead of using `list`, you now use `+`. The order might change, as `S_OBJ` now needs to come first, but unit tests will catch you if you mess up. Also, you will notice that all `S_OBJ` have been increased by one. This is because we used to have `S_TURF(0)` and `S_OBJ(0)`, but with this new trick, -0 == 0, and so they conflicted and needed to be changed. * Sorting how did I miss it Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com> Co-authored-by: Funce <funce.973@gmail.com>
29 lines
1.1 KiB
Plaintext
29 lines
1.1 KiB
Plaintext
GLOBAL_LIST_EMPTY(bitflag_lists)
|
|
|
|
/**
|
|
* System for storing bitflags past the 24 limit, making use of an associative list.
|
|
*
|
|
* Macro converts a list of integers into an associative list of bitflag entries for quicker comparison.
|
|
* Example: list(0, 4, 26, 32)) => list( "0" = ( (1<<0) | (1<<4) ), "1" = ( (1<<2) | (1<<8) ) )
|
|
* Lists are cached into a global list of lists to avoid identical duplicates.
|
|
* This system makes value comparisons faster than pairing every element of one list with every element of the other for evaluation.
|
|
*
|
|
* Arguments:
|
|
* * target - List of integers.
|
|
*/
|
|
#define SET_SMOOTHING_GROUPS(target) \
|
|
do { \
|
|
var/txt_signature = target; \
|
|
if(isnull((target = GLOB.bitflag_lists[txt_signature]))) { \
|
|
var/list/new_bitflag_list = list(); \
|
|
var/list/decoded = UNWRAP_SMOOTHING_GROUPS(txt_signature, decoded); \
|
|
for(var/value in decoded) { \
|
|
if (value < 0) { \
|
|
value = MAX_S_TURF + 1 + abs(value); \
|
|
} \
|
|
new_bitflag_list["[round(value / 24)]"] |= (1 << (value % 24)); \
|
|
}; \
|
|
target = GLOB.bitflag_lists[txt_signature] = new_bitflag_list; \
|
|
}; \
|
|
} while (FALSE)
|