-
-
Notifications
You must be signed in to change notification settings - Fork 629
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
fix: resolve LRU conflicts, cache loss and premature engine breaking change #2988
Conversation
I would like to emphasize that lru-cache is the architecture basis of the proposed project, while methods/features and its functionalities are inspired by quick-lru 🤝 The real advantage is an extensive compatibility and the flexibility to dynamically resize the cache. That said, "lru.min" was primarily optimized based on the use of MySQL2 and is 100% covered throughout E2E based tests: About performance, the benchmarks are created by comparing
# Time:
lru.min: 242.86ms
lru-cache: 264.30ms
# CPU:
lru.min: 280118.00µs
lru-cache: 310327.20µs
In practice, the main difference is how the cache is created ( - new LRU({ max })
+ createLRU({ max }) If there's an interest in merging this PR, that's the repository: lru.min.
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2988 +/- ##
=======================================
Coverage 88.13% 88.13%
=======================================
Files 71 71
Lines 12889 12889
Branches 1352 1352
=======================================
Hits 11360 11360
Misses 1529 1529
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
I upgrade several hundred lambda function functions to a version of mysql2 that included this cache change and I observed no notable issues while testing, We have over 30+ developers / testers working in this environment so I am happy to leave for 24 hours to dogfood this. So far no issues observed, even the deployment / CI phase went as expected without the LRU Constructor cache error. |
Thank you, @robert-pitt-foodhub 🤝 |
This comment was marked as off-topic.
This comment was marked as off-topic.
sorry for lack of input @wellwelwel , been offline for a week. Happy to see this merged! |
ow nice!!! now I can upgrade to version 3 finally!!! thanks |
Fixes #1885, Fixes #1953, Fixes #1965, Fixes #1970, Fixes #2001, Fixes #2537, Fixes #2619, Fixes #2752.
Important
This PR replaces the lru-cache.
LRU is not a constructor
" since it is fully compatible with both CJS and ESM environments, from Node.js 8 onwards using zero pollyfill (it works even in older browsers).16.14
(dropping runtime versions isn't a problem, but it should be done in major releases)setMaxParserCache
is used, MySQL2 overwrites/loses all previous cache (even for a higher size). After this PR, the cache is dynamically resized.⚡️ This brings a minimally performance improvement and uses a little less CPU (but not such a significant difference).
A quick explanation
The motivation 🧑🏻🔬
The two most used projects (lru-cache and quick-lru) that offer the most complete solutions usually dropping Node.js versions (and it's fine). But this situation requires maintainers to also release a major version or continue to use a discontinued/old version.
Based on 7 of 8 linked issues, it started to cause a cascading reaction when each different package made a different decision, causing conflicts when installing the same package in different major versions of the same root project (it's not only a MySQL2 problem).
The solution 💡
I noticed that there was no need for literally ANY pollyfill (even after compilation) to run a LRU cache with even a little more performance (specially for Bun), which is where I decided bringing this dependency to MySQL2.
Recognizing the importance of MySQL2, I will include some details about the reliability of the project in the next comment (please don't associate this with any kind of promotion).