Open pengzhanbo opened 4 days ago
Totals | |
---|---|
Change from base Build 9630744237: | 0.0% |
Covered Lines: | 1084 |
Relevant Lines: | 1675 |
Any reason not to import a LRU package?
I think we might need the memory usage comparison on some large projects.
Totals | |
---|---|
Change from base Build 9630744237: | 0.0% |
Covered Lines: | 1084 |
Relevant Lines: | 1675 |
Totals | |
---|---|
Change from base Build 9630744237: | 0.0% |
Covered Lines: | 1084 |
Relevant Lines: | 1675 |
Totals | |
---|---|
Change from base Build 9630744237: | 0.0% |
Covered Lines: | 1084 |
Relevant Lines: | 1675 |
Totals | |
---|---|
Change from base Build 9630744237: | 0.0% |
Covered Lines: | 1084 |
Relevant Lines: | 1675 |
I think we might need the memory usage comparison on some large projects.
In the new commit, memory cache
and filesystem cache
are provided as optional choices, allowing users to select the appropriate caching solution based on their specific needs.
Totals | |
---|---|
Change from base Build 9630744237: | 0.0% |
Covered Lines: | 1084 |
Relevant Lines: | 1675 |
Before submitting the PR, please make sure you do the following
close #123
).What is the purpose of this pull request?
Description
Vuepress has been criticized for its slow speed.
This is because during the initialization phase, Vuepress needs to compile all markdown files. Although optimizations have been made in
vuepress/core
usingPromise.all()
, the cost ofcreatePage()
remains high, with the main expense coming frommarkdown render()
.In practical use, as we add various markdown-it plugins, including the time-consuming code highlighting plugin, the compilation time remains reasonable when the number of markdown files is small.
However, with a larger quantity, the time overhead increases significantly. It is unnecessary to recompile all markdown files every time Vuepress is started. For content that has not changed, skipping compilation can greatly improve startup speed.
When starting the development server to write markdown files, if there are multiple code blocks, typically we only update certain blocks within one modification cycle. However, when compiling the markdown file, it is still necessary to recompile all code blocks, which is unnecessary.
In fact, highlighting is also a relatively time-consuming operation, especially when using multiple transformers in
shiki
or even usingtwoslash
, the time consumption is quite severe. Therefore, skipping the compilation of unchanged code blocks can greatly reduce the waiting time during hot updates.This plugin does not solve the startup time consumption during the initial compilation, and it may even slightly increase the time taken for the first compilation. However, subsequent startups will benefit greatly from optimization, with larger projects seeing more noticeable effects.
The current approach is to back up all caches to a single cache file, while also writing them to the runtime memory, which might be more convenient for fast reading but could potentially consume too much memory.
Another option is to generate a separate cache file for each markdown file, using file system reading to achieve this. However, this introduces I/O overhead, and the individual I/O overhead for this part might be greater than the render overhead, possibly requiring additional computation to determine whether a file should use the cache.
Screenshots
These startup time screenshots are from the
docs
of this repository.Unuse cache plugin
Use cache plugin, first Launch
Use cache plugin, Secondary Launch