Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[experiment] ropes perf & dedicated SSR codepath#135

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Draft
developit wants to merge3 commits intomain
base:main
Choose a base branch
Loading
fromssr-performance

Conversation

@developit
Copy link
Member

@developitdevelopit commentedFeb 16, 2020
edited
Loading

Update: boo, I botched the benchmark and this is actually slower than master.

I've been sitting on this one for a little bit, and finally got the time to hack it out.

Here's the changes:

No longer reuses renderToString() as an internal method for recursion.
This un-leaks the current private arguments, and enforces monomorphic recursive calls.

Use a "WIP String" reference.
This probably looks weird at first, but it's a JS engine trick. V8 has 11 different String representations, and one of the most highly optimized is called a "rope" (other engines have similar representations). Ropes are "virtual" Strings that are made up of tiny single string pieces - all of thosep.s += 'x' bits. They work a lot like a Buffer, which means they're extremely fast to build up.

In addition to appending String segments to a rope being cheap, there's also a performance benefit to dropping the return value of our recursive function. Instead of the engine having to constantly copy strings returned fromrenderToString(), there is only a single shared reference to the same string. This works really well in our current renderer because we always render depth-first and "top to bottom", so we're always able to append to the end of the WIP string.

Droppingpretty and other options
These are obviously super useful options and we want to have them around - they power a bunch of Preact addons. However, they're almost exclusively used bypreact-render-to-string/jsx, and that's already shipped as its own entry module. I'm proposing we turnimport "preact-render-to-string" into a single-purpose "render my app to HTML", and then usepreact-render-to-string/advanced or something along those lines as a path forward for all of the configurability bits. Or we could just leave it called/jsx and the name will just be slightly wrong from some use-cases.

@developitdevelopit changed the title~40% faster SSR, and ~40% smaller size[experiment] ropes/stringbuilder performance & dedicated SSR codepathFeb 16, 2020
@developitdevelopit changed the title[experiment] ropes/stringbuilder performance & dedicated SSR codepath[experiment] ropes perf & dedicated SSR codepathFeb 16, 2020
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@andrewigginsandrewigginsAwaiting requested review from andrewiggins

@marvinhagemeistermarvinhagemeisterAwaiting requested review from marvinhagemeister

@ForsakenHarmonyForsakenHarmonyAwaiting requested review from ForsakenHarmony

@JoviDeCroockJoviDeCroockAwaiting requested review from JoviDeCroock

@jviidejviideAwaiting requested review from jviide

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@developit

[8]ページ先頭

©2009-2025 Movatter.jp