core icon indicating copy to clipboard operation
core copied to clipboard

[Bug report] Compiling & rendering too too too much slower than VitePress

Open lslzl3000 opened this issue 1 year ago • 21 comments

Description

Try to build with 1000 .md files Vuepress takes more than 10min to compile and render, in both vite-bundler and webpack-bundler

Meanwhile, [email protected] only takes 30s

The core part of build-bundler - Vite is the same, so the problem may be how VuePress processes or organises .md and .vue. What is the difference between VitePress and VuePress during compiling & rendering?

Used Package Manager

npm

System Info

System:
    OS: macOS 12.4
    CPU: (8) arm64 Apple M2
    Memory: 6.52 GB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.15.1 - /usr/local/bin/node
    Yarn: Not Found
    npm: 8.11.0 - /usr/local/bin/npm
  Utilities:
    Git: 2.32.1 - /usr/bin/git
  Browsers:
    Chrome: 103.0.5060.134
    Edge: Not Found
    Firefox: Not Found
    Safari: 15.5
  npmPackages:
System:
    OS: macOS 12.4
    CPU: (8) arm64 Apple M2
    Memory: 6.52 GB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.15.1 - /usr/local/bin/node
    Yarn: Not Found
    npm: 8.11.0 - /usr/local/bin/npm
  Utilities:
    Git: 2.32.1 - /usr/bin/git
  Browsers:
    Chrome: 103.0.5060.134
    Edge: Not Found
    Firefox: Not Found
    Safari: 15.5
  npmPackages:
    @vuepress/bundler-vite: ^2.0.0-beta.49 => 2.0.0-beta.49 
    @vuepress/bundler-webpack: ^2.0.0-beta.49 => 2.0.0-beta.49 
    @vuepress/cli:  2.0.0-beta.49 
    @vuepress/client:  2.0.0-beta.49 
    @vuepress/core:  2.0.0-beta.49 
    @vuepress/markdown:  2.0.0-beta.49 
    @vuepress/plugin-active-header-links:  2.0.0-beta.49 
    @vuepress/plugin-back-to-top:  2.0.0-beta.49 
    @vuepress/plugin-container:  2.0.0-beta.49 
    @vuepress/plugin-docsearch: ^2.0.0-beta.49 => 2.0.0-beta.49 
    @vuepress/plugin-external-link-icon:  2.0.0-beta.49 
    @vuepress/plugin-git:  2.0.0-beta.49 
    @vuepress/plugin-google-analytics: ^2.0.0-beta.49 => 2.0.0-beta.49 
    @vuepress/plugin-medium-zoom:  2.0.0-beta.49 
    @vuepress/plugin-nprogress:  2.0.0-beta.49 
    @vuepress/plugin-palette:  2.0.0-beta.49 
    @vuepress/plugin-prismjs:  2.0.0-beta.49 
    @vuepress/plugin-pwa: Not Found
    @vuepress/plugin-pwa-popup: Not Found
    @vuepress/plugin-register-components: ^2.0.0-beta.49 => 2.0.0-beta.49 
    @vuepress/plugin-search: Not Found
    @vuepress/plugin-shiki: ^2.0.0-beta.49 => 2.0.0-beta.49 
    @vuepress/plugin-theme-data:  2.0.0-beta.49 
    @vuepress/plugin-toc: Not Found
    @vuepress/shared:  2.0.0-beta.49 
    @vuepress/theme-default:  2.0.0-beta.49 
    @vuepress/utils:  2.0.0-beta.49 
    vue:  3.2.37 
    vue-loader:  17.0.0 
    vue-router:  4.0.16 
    vuepress: ^2.0.0-beta.49 => 2.0.0-beta.49 
    vuepress-vite:  2.0.0-beta.49

lslzl3000 avatar Jul 23 '22 08:07 lslzl3000

Hello @lslzl3000. Please provide a minimal reproduction using a GitHub repository or v2.vuepress.vuejs.org/new. Issues marked with need reproduction will be closed if they have no activity within 3 days.

github-actions[bot] avatar Jul 26 '22 06:07 github-actions[bot]

It would be helpful if you could provide a reproduction repo.

meteorlxy avatar Jul 26 '22 06:07 meteorlxy

@meteorlxy I have created a simple repo to test VitePress and VuePress https://github.com/lslzl3000/vuepressVSvitepress

It has about 1000 .md files, just simple doc generated from babylon.js you can try build with VitePress and VuePress

  1. You will see how much longer the VuePress will take
    In my Macbook Pro 2022 with M2, VuePress: 13mins+ vs VitePress:60-70s

  2. VuePress also use much much more memory than VitePress It has to build with NODE_OPTIONS=--max_old_space_size=20480, otherwise node process will exit by JavaScript heap out of memory

If build with full VuePress theme and other plugins, it will take more time

lslzl3000 avatar Jul 27 '22 00:07 lslzl3000

@meteorlxy any progress? closed by bot

lslzl3000 avatar Jul 30 '22 01:07 lslzl3000

This issue is marked as stale because it has not had recent activity. Issues marked with stale will be closed if they have no activity within 3 days.

github-actions[bot] avatar Aug 07 '22 01:08 github-actions[bot]

This issue is marked as stale because it has not had recent activity. Issues marked with stale will be closed if they have no activity within 3 days.

github-actions[bot] avatar Aug 15 '22 01:08 github-actions[bot]

I think we should add a new 'need review' label to stop issue like these closed by bot @meteorlxy

I started to be annoyed about this stale bot

Mister-Hope avatar Aug 18 '22 10:08 Mister-Hope

Any update on this issue? 1500+ md files, build time 23min+: https://github.com/nushell/nushell.github.io/actions/runs/3036416348

hustcer avatar Sep 12 '22 10:09 hustcer

这个问题能不能加急处理下?或者有没有其他什么替代方案?谢谢

hustcer avatar Sep 12 '22 12:09 hustcer

I am focusing this issue these days.

Vitepress loads markdown files directly through a converter, and there is no global "Pages" scope (access other page infomation from one page), which means that vitepress directly luanch a app.

Meanwhile, vuepress have lifecyles, it's tranforming all markdown files to vue compoent and provides "pages data" to let plugins and theme proceed them, also, vuepress is registing all routes at start up and loads pages data with promises.


Besides the structure, one of the reasons which slows down vuepress ssr speed is that we are transforming almost every packages when generating ssr:

https://github.com/vuepress/vuepress-next/blob/bcf6033ce2acf2b98dede4a4e580fe4f39222517/packages/bundler-vite/src/plugins/mainPlugin.ts#L97

So that we will take more time to generate a ssr bundle before proceeing SSG. This is caused by pnpm support. But I do curious about why SSG speed is donzens times slower then vitepress, probably caused by taking much more memory with the "pages map full of promises" .

Mister-Hope avatar Oct 18 '22 08:10 Mister-Hope

@lslzl3000 Would you please run another test with your repo after we migrate to ESM?

Mister-Hope avatar Oct 18 '22 08:10 Mister-Hope

@meteorlxy I have a deeper dig in to our code, pageData only changes during router navigation, but SSG doesn't need those at all, so maybe it could be possible for us to stop loading the whole @internal/pageData, and just load that page Data instead during SSG, I think that will probably reduce memory usage and speed up SSG. Loading all page data through promise when rending any page surely has negative effects during SSG

Mister-Hope avatar Oct 18 '22 08:10 Mister-Hope