You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While profiling the graphql codegen step of one of my company's projects a sharp difference in build time after migrating from near-operation-file to client-preset, we identified that a disproportionate time is spent in these three lines:
You can see that in the flamegraph below, where all of the green traces on the bottom are time spent on those lines — I added a couple arrows to help visualize which trace I mean, but it's all traces of the same color, not just these 4
The reason why that line is so expensive is that this.fragmentsGraph is an expensive getter. In addition to that, it only depends on this._fragments and this._extractFragments(). The this._extractFragments only depends on this._fragments and itself (it's recursive), and this._fragments isn't reassigned or modified (which we verified by changing its declaration to private readonly _fragments: ReadonlyMap<string, LoadedFragment>).
With that in mind, we converted fragmentsGraph from a getter to a regular property, and our build time went from ~130 seconds to ~50s. I'm opening this issue to share our findings and share a PR proposing a related performance improvement.
Your Example Website or App
N/A
Steps to Reproduce the Bug or Issue
Run codegen on a mid-sized project using client-preset and measure the build time
Make the change to only compute fragmentsGraph once per ClientSideBaseVisitor instance
Run codegen again and compare the build time
Expected behavior
client-preset should be faster by avoiding costly recomputations of unchanged data
Which packages are impacted by your issue?
@graphql-codegen/visitor-plugin-common
Describe the bug
While profiling the graphql codegen step of one of my company's projects a sharp difference in build time after migrating from
near-operation-file
toclient-preset
, we identified that a disproportionate time is spent in these three lines:You can see that in the flamegraph below, where all of the green traces on the bottom are time spent on those lines — I added a couple arrows to help visualize which trace I mean, but it's all traces of the same color, not just these 4
The reason why that line is so expensive is that
this.fragmentsGraph
is an expensive getter. In addition to that, it only depends onthis._fragments
andthis._extractFragments()
. Thethis._extractFragments
only depends onthis._fragments
and itself (it's recursive), andthis._fragments
isn't reassigned or modified (which we verified by changing its declaration toprivate readonly _fragments: ReadonlyMap<string, LoadedFragment>
).With that in mind, we converted
fragmentsGraph
from a getter to a regular property, and our build time went from ~130 seconds to ~50s. I'm opening this issue to share our findings and share a PR proposing a related performance improvement.Your Example Website or App
N/A
Steps to Reproduce the Bug or Issue
client-preset
and measure the build timefragmentsGraph
once perClientSideBaseVisitor
instanceExpected behavior
client-preset
should be faster by avoiding costly recomputations of unchanged dataScreenshots or Videos
No response
Platform
graphql
version: 16.2.0@graphql-codegen/client-preset
version(s): 4.2.6@graphql-codegen/visitor-plugin-common
version(s): 2.13.1Codegen Config File
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: