Open valarnin opened 2 years ago
Oooh, interesting! Thanks for the analysis. Which popup-text.ts
lines are those? I'm not quite sure I follow what the output is pointing at here.
Sorry, I had forgotten that I had played around with fixes between when I originally ran the first trace and when I re-did the analysis for opening this issue. Updated the trace outputs above to actually match the main
code.
It's a standard trace tree, so it starts from more generic (file-level) and works down to more specific (exact token).
So for popup-text.ts
, it's saying type checking the entire file takes 2467ms
to compile.
Type checking the segment from 697:11 -> 697:39
took 1918ms
of that 2467ms
time. (this.ProcessTrigger(trigger)
)
Type checking the segment from 697:31 -> 697:38
took 1915ms
of that 1918ms
time. (trigger
)
Basically, it's saying that type checking the trigger
parameter is taking almost 2 full seconds.
I did a little digging in here, and this is my tracing baseline:
Currently (after the patch of new trigger style), the slowness of popup-text.ts
file is beacuse when getting or setting a property of trigger (like trigger.id
), it need to narrow the type of trigger (here it's BaseTrigger<RaidbossData, "GameLog"> & PartialNetRegexTrigger<"GameLog"> & Partial<BaseTrigger<RaidbossData, "None"> & PartialRegexTrigger & PartialNetRegexTrigger<...>>) | ... 39 more ... | (BaseTrigger<...> & ... 2 more ...
) to anyone of them, and it's really slow (tsc even can't show the full list!).
And it's not hard to solve, we create a new variable const processed: ProcessedTrigger = {}
and copy all fields, and set property to this new processed trigger, and orderedTriggers.push(processed);
roughly like this:
But popup-text.ts
only take 1s in my all 35s building.
most of the time is spending on checking the type of TriggerSet<Data>
, and to be more to be more specific, checking triggers?: NetRegexTrigger<Data>[];
, and I didn't find a real solution for that.
There are 41 netLog types and we have no way to reduce that, so in any case there will be more than (41+m)*N type union to narrow, but we can try to reduce the union of trigger type by make N=1.
by merging BaseTrigger
with PartialNetTrigger
, this reduce 35s to 31s:
This doesn't make any actually change on types, it just speedup type narrow on triggers, this even help to reduce the time spending on popup-text.ts
And currently we have 254 raidboss triggers, I guess maybe is just too many files for tsc...
Summary
There are a number of code paths that slow
tsc
execution.Steps taken to check:
npm i -g @typescript/analyze-trace
npm run tsc-no-emit -- --generateTrace ../cactbot-tracing
npx analyze-trace ../cactbot-tracing --force-millis 300
Results:
I'm not sure what can be done about large trigger files, but the
popup-text.ts
andtest_trigger.ts
cases could probably be improved?