-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf: improve ssr performance #1068
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a small tweak
@@ -2,6 +2,10 @@ import SmoothScroll from 'smooth-scroll/dist/smooth-scroll.js' | |||
|
|||
export default { | |||
created () { | |||
if (this.$ssrContext) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this file has been removed for now since we deprecated smooth scroll.
@@ -128,12 +126,14 @@ export function resolveSidebarItems (page, regularPath, site, localePath) { | |||
} | |||
|
|||
const sidebarConfig = localeConfig.sidebar || themeConfig.sidebar | |||
let normalizedPagesMap = {} | |||
pages.forEach(page => normalizedPagesMap[normalize(page.regularPath)] = page); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe following style would be more refreshing:
const normalizedPagesMap = pages.reduce((map, page) => map[normalize(page.regularPath)] = page, {})
@ulivz i'll update the PR tomorrow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to figure out why the build process failed before I started to merge it.
@ulivz fixed! |
path: ensureExt(pages[i].path) | ||
}) | ||
} | ||
if (path in pages) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This changes the function signature but doesn't update all the callers. resolvePage is also called from the default theme. See vuepress/packages/@vuepress/theme-default/components/Page.vue computed.prev. which is now broken and gives an error when trying to use frontmatter prev / next links. See #1140 for a primitive fix. Thanks.
fixes bug introduced with vuejs#1068.
Reverted this change at b24c317 for now. |
Summary
Improve ssr performance by caching items when resolving sidebar items. Fix memory leak in root mixins.
What kind of change does this PR introduce? (check at least one)
We are testing VuePress on a huge API documentation which currently has over 400 pages. 200 of those pages are reachable via the sidebar in different sidebar groups. We experienced very slow build times (ranging from 300 - 800ms per page) and crashes due to heap out of memory.
After a little investigation we identified that resolving of sidebar items is responsible for slow build times. This introduces a simple map that stores page objects for each normalized path for faster lookups. The build times are now back to a reasonable 50-100ms for each page.
The crash was caused by the
updateLoadingState
mixin, which apparently contains client only code that does not make much sense to run on the server. The event handler bindings in that mixin will lead to a memory leak since the components will never be released.Does this PR introduce a breaking change? (check one)
The PR fulfills these requirements:
fix #xxx[,#xxx]
, where "xxx" is the issue number)You have tested in the following browsers: (Providing a detailed version will be better.)
Other information:
Tested on Node v10.13.0
#966 may be related.
For a reproducible test case, clone https://github.com/appcelerator/titanium-vuepress-docs and build with
npm run docs:build