Vuepress building is too slow ?!

[JimmyVV]

• I confirm that this is an issue rather than a question.

Bug report

My project is large, it maybe contain 6000 markdown files. Once, I meet the dev performance problem, and I solve it by this command node --max_old_space_size=8192 ./node_modules/vuepress/cli.js dev src.

But, when I run building production, the process is too slow. I also modify the building command with node --max_old_space_size=8192 ./node_modules/vuepress/cli.js build src. Unfortunately, it doesn't work.

Version

"vuepress": "^1.0.0-alpha.47",

Steps to reproduce

What is expected?

What is actually happening?

Other relevant information

• Your OS: MAC
• Node.js version: 8.11
• Browser version:
• Is this a global or local install? local
• Which package manager did you use for the install?
• Does this issue occur when all plugins are disabled?

[JimmyVV]

the renderer.renderToString takes up much time.

more than 4 seconds

# analyse code
 try {
      console.time('start');
      html = await this.renderer.renderToString(context)
      console.timeEnd('start');
    } catch (e) {
      console.error(logger.error(chalk.red(`Error rendering ${pagePath}:`), false))
      throw e
    }

[JimmyVV]

after I improve the ssr performance, the time reduce to 60+ms

Rendering page: /dev/api-backend/open-api/express/by-provider/logistics.onGetQuota.htmlstart: 822.013ms

However, the more markdown files it compile, it will need more time.

the result is :

plate-message/templateMessage.getTemplateLibraryList.htmlstart: 808.080ms
Rendering page: /miniprogram/dev/api-backend/open-api/template-message/templateMessage.send.htmlstart: 789.571ms
Rendering page: /miniprogram/dev/api-backend/open-api/template-message/templateMessage.getTemplateList.htmlstart: 807.422ms
Rendering page: /miniprogram/dev/api-backend/open-api/uniform-message/uniformMessage.send.htmlstart: 802.172ms
Rendering page: /miniprogram/dev/api-backend/open-api/updatable-message/updatableMessage.createActivityId.htmlstart: 812.487ms
Rendering page: /miniprogram/dev/api-backend/summary.part.htmlstart: 768.504ms
Rendering page: /miniprogram/dev/api-backend/open-api/updatable-message/updatableMessage.setUpdatableMsg.htmlstart: 834.227ms
Rendering page: /miniprogram/dev/api-backend/open-api/user-info/auth.getPaidUnionId.htmlstart: 848.840ms
Rendering page: /miniprogram/dev/api/ad/InterstitialAd.offError.htmlstart: 783.710ms

[JimmyVV]

@ulivz Help!

[JimmyVV]

I am using the default theme, which causes memory leaks.

[mandaputtra]

I maybe consider doing this with different approach if there are 6000 markdown file. Or maybe different tools. Yes it will slow because rendering/parsing markdown itself are heavy.

if you cant, I consider to make it smaller by separate the docs file.

[ulivz]

First of all, why is it slow? The compilation time depends on the size of the content you build. You have 6000 files to compile, isn't that slow?

Secondly, let's talk about the necessity of this issue. You can try any other static website building tool to build it. If they are very fast, please use accurate data to show that slow construction is a unique issue of vuepress.

[JimmyVV]

?? the number of files doesn't matter, the point is the compilation time. And When I change back 0.11, the renderString time reduce to 50ms per page.

I also analyse the memory usage, that actually indicate memory leaks do happen in vuepress@beta.

[xbill82]

@ulivz I wouldn't wipe this issue out so quickly. Sure @JimmyVV should provide more data but I'm migrating a documentation (5000+ files) from Metalsmith to VuePress and the main issue we have now is that we can't deploy on Netlify because the build time is longer than the maximum build timeout. Metalsmith did build the whole doc within Netlify's timeouts.

Ok, Vuepress' build process is surely more complex than Metalsmith and Vuepress is indeed a better tool, but yet... The build time is incredibly bigger in VP and this is strange.

So this is meant to add some data to the "comparison with other static website building tools" you asked above, @ulivz .

@JimmyVV please, would you post your investigations about memleaks introduced by the default theme?

Another point that cannot be ignored is that when @JimmyVV downgrades, the perfs are better. I definitely think we should look into this.

[xbill82]

UPDATE: I am currently building my documentation (as mentioned above, 5000+ files) using Travis CI and my build job times out after 2h (the same job worked fine with Metalsmith -- not meaning to say Metalsmith was a better tool, just faster).

It seems weird.

[xbill82]

UPDATE: Switching to Node v10.x actually speeds up the build time. We are now able to build in Travis, but an issue is still present.
We noticed that the build time per-file slows down during the build. It looks like there's some kind of leak (more CPU than memory) slowing things down.

[ProTip]

It appears that part of the build process spins up many node processes however at least with the standard build command rendering the static content only utilizes a single node process. Perhaps utilizing available cores for static content generation would speed this up greatly for people?