| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
TypeScript Bot (@typescript-bot) perf test this faster |
Sorry, something went wrong.
|
Heya Wesley Wigham (@weswigham), I've started to run the abridged perf test suite on this PR at e9d86d9. You can monitor the build here. Update: The results are in! |
Sorry, something went wrong.
|
Wesley Wigham (@weswigham) Comparison Report - main..50245
System
Hosts
Scenarios
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sorry, something went wrong.
|
Daniel Rosenwasser (@DanielRosenwasser) good news! The perf improvements aren't from the switch-case change, and I'm not going crazy reading the v8 source code, unable to figure out why the switch was deoptimized (when, in fact, it wasn't)! Just extracting the various cases into individual functions looks to be most if not all of the performance improvement. So it looks like it's not the switch that's an issue, but rather the length and polymorphism of the function itself. |
Sorry, something went wrong.
|
TypeScript Bot (@typescript-bot) perf test this For LS numbers for this, too~ |
Sorry, something went wrong.
|
Heya Wesley Wigham (@weswigham), I've started to run the perf test suite on this PR at e9d86d9. You can monitor the build here. Update: The results are in! |
Sorry, something went wrong.
|
Wesley Wigham (@weswigham)
CompilerComparison Report - main..50245
System
Hosts
Scenarios
TSServerComparison Report - main..50245
System
Hosts
Scenarios
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sorry, something went wrong.
|
I do like the improved safety of this one over #50225. Would the perf be identical if these functions were instead declared at the bottom of forEachChild? That way, nobody could actually try and call them. (This is probably very moot post-modules, as this whole thing could be its own file that doesn't export them.) |
Sorry, something went wrong.
|
I wonder if V8 is using a jump table for the switch now that it has no fall-through cases.
These functions don't need to be exported from ts either and it might make sense to just move forEachChild et all to its own file anyways. |
Sorry, something went wrong.
|
I ultimately like Daniel Rosenwasser (@DanielRosenwasser) 's PR more, simply because it is yet more performant, but it looks like the perf improvement is correlated with the instruction length of the function and not the presence or lack thereof of the switch, which is what I wanted to confirm with this. |
Sorry, something went wrong.
Based on the conditions for switch optimization I read in the v8 sources, both before this PR and with this PR, the switch should be optimized to a jump table. For an interpreted function, you get a jump table so long as you have a minimum number of branches and cover at least 33% of the range of inputs (measured as the difference between the min and max case values). On x64, for a compiled function, there's a somewhat complex space/time tradeoff heuristic where it falls back to a binary search, but it weights the time metric more, and for anything with a somewhat densely filled out list of cases, should prefer the jump table. There's links to the relevant v8 sources in our internal discussions, if you're curious about the exact heuristic. AFAIK, the 128 case limit mentioned in the recently-trended blog post about a perf problem from 2013 no longer seems to exist - on x64, the max case count for a jump table is 2 << 16. (And fall throughs don't seem to affect it in any way - they count as a case same as any other) |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Just to see if this alone has a perf diff.