perf(schema-compiler): More aggressive compilers cleanup

[KSDaemon]

This simple fix cleans up references to data schema compilers instances within dispose() method during cache eviction. This slightly improves memory performance by allowing GC to clean up unused memory earlier.

While it won't be noticed in most cases, these changes might be useful for highload scenarios with huge data models.

Here are some insights. Pay attention to the Total Heap Allocated curve.

BEFORE:

AFTER:

Check List

• Tests have been run in packages where changes have been made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.73%. Comparing base (258be19) to head (9f7ad08).

❗ There is a different number of reports uploaded between BASE (258be19) and HEAD (9f7ad08). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (258be19)	HEAD (9f7ad08)
cubesql	1	0

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #10153       +/-   ##
===========================================
- Coverage   83.29%   54.73%   -28.56%     
===========================================
  Files         244      213       -31     
  Lines       74180    16916    -57264     
  Branches        0     3337     +3337     
===========================================
- Hits        61786     9259    -52527     
+ Misses      12394     7179     -5215     
- Partials        0      478      +478     

Flag	Coverage Δ
cube-backend	54.73% <100.00%> (?)
cubesql	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ovr]

Awesome! New trick in my collection!

I have a gut feeling that it's better to add flag and guard methods, so that the object is destroyed. this.destroyed = true. Maybe a decorator or something.

If it crashes somehow, it will be impossible to detect why it's crashing.
All our code is async, some users can change size of compiler cache, in this case, it's possible that some code can have a reference to CompilerApi object, while lru will fire despose that compilerAPi.dispose.

After 4 years on Rust language, I already have a panic passion for protecting such places.

WDYT?