Skip to content
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

Very poor graphql performance with gatsby-plugin-mdx when compared with gatsby-transformer-remark #29438

Closed
epbarger opened this issue Feb 10, 2021 · 1 comment
Assignees
Labels
type: bug An issue or pull request relating to a bug in Gatsby

Comments

@epbarger
Copy link

epbarger commented Feb 10, 2021

Description

In a gatsby app set up with a non-trivial amount of MDX files (500 4kb files), graphql performance seems to be much slower than expected, both the source and transform nodes step, and the page queries step. Here are the times I've recorded during build, running in a github action for comparison purposes.

MDX Action
Markdown Action

transform and source page queries
MDX 100.507s 164.552s - 505/505 3.07/s
Markdown 1.293s 27.288s - 505/505 18.51/s

Steps to reproduce

I've created a minimal reproduction here. This is just the starter project with gatsby-plugin-mdx added, a basic gatsby-node file to create the pages, and a basic template with a simple page query. master uses gatsby-plugin-mdx, markdown uses gatsby-transformer-remark.

Expected result

I'm expecting some increase in the transform and source step (though ideally not a 100x increase like I'm seeing), since obviously MDX is much more complex than plain markdown. But I'm not expecting to see such a large increase in page query time for MDX node queries.

Actual result

The current times make building any large MDX-based site extremely painful! The gatsby cache helps alleviate the page query pain (but not the sourcing/tranformations), but isn't something we can rely on for every build.

I'm working on an open-source documentation website that is leveraging MDX. Currently, at 1500 pages, we're really feeling the pain of these slow builds, and our site will easily double or triple in content size soon. So we're extremely interested in any possibilities to increase the build speed of MDX-based gatsby apps.

Any help or suggestions are extremely appreciated, thank you!

Environment

This from my local, not the github actions, but it may still be useful as I experience very similar times locally.

  System:
    OS: macOS Mojave 10.14.4
    CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 14.15.4 - ~/.nvm/versions/node/v14.15.4/bin/node
    Yarn: 1.22.10 - ~/.nvm/versions/node/v14.15.4/bin/yarn
    npm: 6.14.10 - ~/.nvm/versions/node/v14.15.4/bin/npm
  Languages:
    Python: 2.7.15 - /usr/local/bin/python
  Browsers:
    Chrome: 88.0.4324.150
    Firefox: 83.0
    Safari: 12.1
  npmPackages:
    gatsby: ^2.32.3 => 2.32.3
    gatsby-image: ^2.11.0 => 2.11.0
    gatsby-plugin-manifest: ^2.12.0 => 2.12.0
    gatsby-plugin-mdx: ^1.10.0 => 1.10.0
    gatsby-plugin-offline: ^3.10.0 => 3.10.0
    gatsby-plugin-react-helmet: ^3.10.0 => 3.10.0
    gatsby-plugin-sharp: ^2.14.1 => 2.14.1
    gatsby-source-filesystem: ^2.11.0 => 2.11.0
    gatsby-transformer-remark: ^2.16.0 => 2.16.0
    gatsby-transformer-sharp: ^2.12.0 => 2.12.0
  npmGlobalPackages:
    gatsby-cli: 2.17.0
@epbarger epbarger added the type: bug An issue or pull request relating to a bug in Gatsby label Feb 10, 2021
@gatsbot gatsbot bot added the status: triage needed Issue or pull request that need to be triaged and assigned to a reviewer label Feb 10, 2021
@ascorbic ascorbic added topic: scaling builds and removed status: triage needed Issue or pull request that need to be triaged and assigned to a reviewer labels Feb 11, 2021
@ascorbic
Copy link
Contributor

There's some discussion on this here: #22521

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug An issue or pull request relating to a bug in Gatsby
Projects
None yet
Development

No branches or pull requests

3 participants