Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MIRROR] Refactors fancy type generation #1863

Merged
merged 1 commit into from
Feb 9, 2024
Merged

Conversation

Steals-The-PRs
Copy link
Collaborator

Mirrored on Nova: NovaSector/NovaSector#844
Original PR: tgstation/tgstation#81259

About The Pull Request

Refactors fancy type generation

Ok so we have this proc that generates concatenated names for types so admins have a nice list to sort through.

The trouble is this is done by, for each type, iterating all possible replacements, and seeing which ones apply (with expensive string operations)

A clean run of this applied to all datums takes about 3.5 seconds on my pc.
This sucks.

Ok so can we do better. Well, yes, pretty easily.

Rather then, for each potential type, iterating all the options, let's build a zebra typecache (a lookup list of type -> string to use), and use that.
Then we can use a list of replacement -> the bit to tear out to figure out what to remove.

This works quite well. It does mean that we're doing it based off the type tree and not type paths, so if we didn't have a replacement for like, mob, it'd look weird, but we don't have cases like that so it's fine.

Or well we sorta did, didn't have anything for atom movables or areas, but I fixed that so sall good.

Anyway, we only need to do this work once. It takes about 0.3 seconds on my machine, so we can cache it.

Just this on its own would technically slow init, since we have a some code that's running this proc off static, but we can just not, that's fine (technically saves init time too since we don't have to burn 0.1 seconds on it anymore).

This brings the cost of generating this list for all datums from 3 seconds to 0.16, assuming we have the static pre generated.

We could in theory pre-generate just like, all the strings?
But I don't think the cached cost is high enough for that to be a real problem. IDK open to other thoughts

Oh also I had to reorder the strings in that list, cause zebra_typecacheof has reverse priority. s life

Updates stat tracking macro to work at world start

It for some reason doesn't actually get anything this early, but now at least the logging would in theory function

Why It's Good For The Game

Better response times for admins, faster code, more better

* Refactors fancy type generation (#81259)

## About The Pull Request

[Refactors fancy type
generation](tgstation/tgstation@3f218ac)

Ok so we have this proc that generates concatenated names for types so
admins have a nice list to sort through.

The trouble is this is done by, for each type, iterating all possible
replacements, and seeing which ones apply (with expensive string
operations)

A clean run of this applied to all datums takes about 3.5 seconds on my
pc.
This sucks.

Ok so can we do better. Well, yes, pretty easily.

Rather then, for each potential type, iterating all the options, let's
build a zebra typecache (a lookup list of type -> string to use), and
use that.
Then we can use a list of replacement -> the bit to tear out to figure
out what to remove.

This works quite well. It does mean that we're doing it based off the
type tree and not type paths, so if we didn't have a replacement for
like, mob, it'd look weird, but we don't have cases like that so it's
fine.

Or well we sorta did, didn't have anything for atom movables or areas,
but I fixed that so sall good.

Anyway, we only need to do this work once. It takes about 0.3 seconds on
my machine, so we can cache it.

Just this on its own would technically slow init, since we have a some
code that's running this proc off static, but we can just not, that's
fine (technically saves init time too since we don't have to burn 0.1
seconds on it anymore).

This brings the cost of generating this list for all datums from 3
seconds to 0.16, assuming we have the static pre generated.

We could in theory pre-generate just like, all the strings? 
But I don't think the cached cost is high enough for that to be a real
problem. IDK open to other thoughts

Oh also I had to reorder the strings in that list, cause
zebra_typecacheof has reverse priority. s life

[Updates stat tracking macro to work at world
start](tgstation/tgstation@1fbfb70)

It for some reason doesn't actually get anything this early, but now at
least the logging would in theory function

## Why It's Good For The Game

Better response times for admins, faster code, more better

* Refactors fancy type generation

---------

Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
@ReezeBL ReezeBL merged commit 4bba66e into master Feb 9, 2024
24 checks passed
@ReezeBL ReezeBL deleted the upstream-mirror-844 branch February 9, 2024 10:13
Iajret pushed a commit that referenced this pull request Apr 7, 2024
* Reverts reversion: tgui will 516 or else (#82527)

## About The Pull Request
Context: #82522

Apparently you cant just stuff the byond helper functions into an
external js file, but if you do, byond won't even let you know its a
problem until the servers crash and you have to run `bin/clean` just to
unbork your entire repo

This reimplements the changes from #82473 without:
- moving the byond helper functions externally
- causing a tooltip render issue in panel

## Why It's Good For The Game
516 prep (again this time)

* Reverts reversion: tgui will 516 or else

---------

Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants