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.

Sign up for GitHub

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

Jump to bottom

Add benchmarking for MDX parsing and compiling performance #1044

Closed
johno opened this issue Apr 30, 2020 · 3 comments
Closed

Add benchmarking for MDX parsing and compiling performance #1044

johno opened this issue Apr 30, 2020 · 3 comments
Labels
🏁 area/perf This affects performance 🕸️ area/tests This affects tests good first issue 👋 This may be a great place to get started! help wanted 🙏 This could use your insight or help 🦋 type/enhancement This is great to have 💎 v2 Issues related to v2 🙆 yes/confirmed This is confirmed and ready to be worked on
Milestone
v2

Comments

@johno
Copy link
Member

johno commented Apr 30, 2020

We should have a handful of documents that we benchmark so we know:

  • baseline MDX parsing performance
  • are notified when performance regresses significantly

We should probably consider also benchmarking rendering for React/Preact/Vue as well.
@johno johno added 🦋 type/enhancement This is great to have help wanted 🙏 This could use your insight or help good first issue 👋 This may be a great place to get started! 🕸️ area/tests This affects tests 🙆 yes/confirmed This is confirmed and ready to be worked on 🏁 area/perf This affects performance labels Apr 30, 2020
@johno johno mentioned this issue Apr 30, 2020
Closed
25 tasks
@johno johno added the 💎 v2 Issues related to v2 label Apr 30, 2020
@johno johno added this to the v2 milestone Jul 22, 2020
@cesutherland
Copy link

Related — https://github.com/mdx-js/mdx/compare/benchmarks

@cesutherland
Copy link

Quick error-handling addition: #1205

The spike looks good to me! It'd be nice to get this into 1.6, in order to have a "benchmark" for v2. I could see the benchmarks themselves living inside individual packages, or at the top level like they are here. Have any opinion on that @johno ?

wooorm added a commit that referenced this issue Dec 23, 2020
@wooorm
Remove JSX from output by default
3dbd901 
Previously, we required an extra build step to produce runnable code.
This change makes the output of MDX immediately runnable.

This drops the final requirement on Babel (Or Bublé).
Dropping Babel leads to a size and performance win for the runtime (and for
any use case that doesn’t otherwise require Babel, such as running in Node).
Of course, if people want to use the latest JavaScript features, they can still
use Babel, but it’s not *required*.

Finally, if JSX is preferred (for example, Vue treats JSX radically different
from other hyperscript interfaces and has its own JSX builders), `keepJsx` can
be set to `true`.

In short, the size breakdown for the runtime is:

* `@mdx-js/[email protected]` (last stable tag): 356.4kb
* `@mdx-js/[email protected]` (last next tag): 362.9kb
* Previous commit (on an unmaintained Bublé fork): 165kb
* This commit: 120kb (26% / 66% / 69% smaller)

Core only adds ±1kb to its bundle size, because `estree-util-build-jsx`
reuses dependencies that we already use, too.

Related to GH-1041.
Related to GH-1044.
Related to GH-1152.
@wooorm wooorm mentioned this issue Dec 23, 2020
Closed
wooorm added a commit that referenced this issue Dec 28, 2020
@wooorm
Remove JSX from output by default
f262f45 
Previously, we required an extra build step to produce runnable code.
This change makes the output of MDX immediately runnable.

This drops the final requirement on Babel (Or Bublé).
Dropping Babel leads to a size and performance win for the runtime (and for
any use case that doesn’t otherwise require Babel, such as running in Node).
Of course, if people want to use the latest JavaScript features, they can still
use Babel, but it’s not *required*.

Finally, if JSX is preferred (for example, Vue treats JSX radically different
from other hyperscript interfaces and has its own JSX builders), `keepJsx` can
be set to `true`.

In short, the size breakdown for the runtime is:

* `@mdx-js/[email protected]` (last stable tag): 356.4kb
* `@mdx-js/[email protected]` (last next tag): 362.9kb
* Previous commit (on an unmaintained Bublé fork): 165kb
* This commit: 120kb (26% / 66% / 69% smaller)

Core only adds ±1kb to its bundle size, because `estree-util-build-jsx`
reuses dependencies that we already use, too.

Related to GH-1041.
Related to GH-1044.
Related to GH-1152.
@wooorm
Copy link
Member

wooorm commented Oct 19, 2021

closing for now, would be good to revisit if large changes are planned again. But the new RC (see: https://v2.mdxjs.com) is much faster on several benchmarks I performed.

@wooorm wooorm closed this as completed Oct 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
🏁 area/perf This affects performance 🕸️ area/tests This affects tests good first issue 👋 This may be a great place to get started! help wanted 🙏 This could use your insight or help 🦋 type/enhancement This is great to have 💎 v2 Issues related to v2 🙆 yes/confirmed This is confirmed and ready to be worked on
Milestone
v2
Development

No branches or pull requests
3 participants
@cesutherland @wooorm @johno