refactor: shared module table at PluginContext
Description
The pr intend to support PluginContext#getModuleInfo, before i already support NormalModule cast to ModuleInfo, it only work at moduleParesd hook. But the PluginContext#getModuleInfo need to valid at plugin lifetime. I consider two ways to support it.
A. Add a moduleInfos(Dashmap) to owner ModuleInfoat PluginContext, but it need to set the module info when the ModuleInfo fields change, it need to re-set many times, due to https://rollupjs.org/plugin-development/#this-getmoduleinfo. It also has some overhead if the plugin not used it.
B. Shared ModuleTable at PluginContext, the typing is Arc<RwLock<ModuleTable>>, we only need to muate it at module loader and sort modules, it always do it at single thread, so we are using RwLock to avoid caused performance regression if lock conflict. Other, TheModuleInfo will be lazy, if you used it, it will cast from NormalModule.
The pr intend to implement B, it is sound good to me. If you have some good ideas, please let know.
The mutate SharedModuleTable is not finished at module loader, it look like is complex, i intend to do it at next pr.
Deploy Preview for rolldown-rs canceled.
| Name | Link |
|---|---|
| Latest commit | f80d1d8599ad12fda103219708596f3b519f43ab |
| Latest deploy log | https://app.netlify.com/sites/rolldown-rs/deploys/664608257d49b00008bcffb4 |
Deploy Preview for rolldown-rs canceled.
| Name | Link |
|---|---|
| Latest commit | 55d727d6737de3c12e52f2d7252178c6f374c00f |
| Latest deploy log | https://app.netlify.com/sites/rolldown-rs/deploys/6646082e0e89090009219e57 |
Codecov Report
Attention: Patch coverage is 93.14286% with 12 lines in your changes are missing coverage. Please review.
Project coverage is 86.90%. Comparing base (
130013b) to head (55d727d). Report is 1 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #1144 +/- ##
==========================================
- Coverage 86.95% 86.90% -0.05%
==========================================
Files 122 122
Lines 6018 6064 +46
==========================================
+ Hits 5233 5270 +37
- Misses 785 794 +9
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Benchmarks Rust
- target:
main(594c144a8936689ccdc2a9df78efa89c38347357) - pr:
shared-module-table(55d727d6737de3c12e52f2d7252178c6f374c00f)
group pr target
----- -- ------
rolldown benchmark/threejs-bundle 1.00 28.9±0.42ms ? ?/sec 1.01 29.1±0.38ms ? ?/sec
rolldown benchmark/threejs-scan 1.03 20.8±1.67ms ? ?/sec 1.00 20.2±0.09ms ? ?/sec
rolldown benchmark/threejs-sourcemap 1.02 41.3±1.64ms ? ?/sec 1.00 40.5±1.01ms ? ?/sec
rolldown benchmark/threejs10x-bundle 1.01 310.3±2.31ms ? ?/sec 1.00 308.1±1.87ms ? ?/sec
rolldown benchmark/threejs10x-scan 1.00 202.2±2.03ms ? ?/sec 1.01 204.7±4.43ms ? ?/sec
rolldown benchmark/threejs10x-sourcemap 1.02 448.9±12.95ms ? ?/sec 1.00 440.0±11.25ms ? ?/sec
CodSpeed Performance Report
Merging #1144 will not alter performance
Comparing shared-module-table (55d727d) with main (130013b)
Summary
✅ 6 untouched benchmarks
I give a rough look, it's not worth to wrap ModuleTable in Arc<Mutex<...>> just for support this.getModuleInfo.
Compatibility not comes first. If we can't implement a compatible feature in reasonable way, we either try to find other ways or just give up the feature temperately. The compatible feature should not deeply affects the internal core code of rolldown
Compatibility not comes first. If we can't implement a compatible feature in reasonable way, we either try to find other ways or just give up the feature temperately. The compatible feature should not deeply affects the internal core code of rolldown
I'm also agree it, I'm not sure for the compatibility, let us discuss it at the meeting.