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

perf: Use a faster check for empty schemas #10444

Merged
merged 2 commits into from
Aug 19, 2022
Merged

Conversation

AaronFriel
Copy link
Member

@AaronFriel AaronFriel commented Aug 18, 2022

Experimentally, this can reduce time taken in calls to load a schema by 1-3 seconds, which for a Pulumi YAML program execution or call to pulumi convert (on the order of 5-10s) is a significant performance improvement.

The benchmark showed that prior to this change, the benchmark took 1.1 to 2.5 seconds on a relatively recent Intel laptop processor:

Before:

goos: linux
goarch: amd64
pkg: github.com/pulumi/pulumi/pkg/v3/codegen/schema
cpu: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz
BenchmarkSchemaEmptyCheck
BenchmarkSchemaEmptyCheck/large-schema-empty-check-time
BenchmarkSchemaEmptyCheck/large-schema-empty-check-time-8
       1	1734625270 ns/op	    6768 B/op	      22 allocs/op
PASS

(That's 1.7 seconds/operation, sample size of 1.)

After:

BenchmarkSchemaEmptyCheck/large-schema-empty-check-time-8
        1000000000	         0.0000005 ns/op	       0 B/op	       0 allocs/op

It's now on the order of a couple instructions, apparently too short for Go benchmarking to analyze (it is definitely not that much shorter than a nanosecond) as for most non-empty schemas we will return "false" within reading the first few bytes of a file.


Addenda: Out of curiosity I changed the regexp to include a ^ at the beginning, and that vastly improved performance. Still, the new approach is clear that we're willing to try to parse almost any document, just not the defaults that some providers have used.

BenchmarkSchemaEmptyCheck/large-schema-empty-check-time-8
        1000000000	         0.0000130 ns/op	       0 B/op	       0 allocs/op
PASS

Again with the very tiny time per operation, a clock cycle on this computer is on the order of 0.25ns.

@pulumi-bot
Copy link
Contributor

Please view the results of the Downstream Codegen Tests Here

@pulumi-bot
Copy link
Contributor

Please view the results of the Downstream Codegen Tests Here

@AaronFriel AaronFriel requested review from iwahbe and a team August 18, 2022 23:56
@pulumi-bot
Copy link
Contributor

Please view the results of the Downstream Codegen Tests Here

@pulumi-bot
Copy link
Contributor

Please view the results of the Downstream Codegen Tests Here

@pulumi-bot
Copy link
Contributor

Please view the results of the Downstream Codegen Tests Here

Copy link
Member

@Frassle Frassle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

eh sure, I imagine over time this becomes such a corner case that speed won't matter but it's not over complicated

@AaronFriel AaronFriel merged commit 94aab98 into master Aug 19, 2022
@pulumi-bot pulumi-bot deleted the friel/faster-schema-empty branch August 19, 2022 14:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants