这是indexloc提供的服务,不要输入任何密码
Skip to content

type-contract: merge vector and hash types earlier #1282

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

Merged
merged 3 commits into from
Sep 20, 2022

Conversation

bennn
Copy link
Contributor

@bennn bennn commented Sep 10, 2022

Context:
(Vector T) is implemented as the union of two types. Enforcing the
type with two contracts is inefficient; we want one merged contract.
Same for (HashTable K V), which is implemented as three types.

This commit replaces the old static-contract merging with a type merging.

The problem with static contract merging is that it happens after the "typed-side" optimization kicks in --- which meant that two types with equal components could end up as static contracts with unequal components. This was a huge practical problem in the GTP benchmark dungeon ... the fix lowers the runtime for one loop in the worst case down from 30 seconds to 1/2 second.

Context:
  (Vector T) is implemented as the union of two types. Enforcing the
  type with two contracts is inefficient; we want one merged contract.
  Same for (HashTable K V), which is implemented as three types.

This commit replaces the old static-contract merging with a type
merging.

The problem with static contract merging is that it happens after
the "typed-side" optimization kicks in --- which meant that two
types with equal components could end up as static contracts with
unequal components. This was a huge practical problem in the GTP
benchmark `dungeon` ... the fix lowers the runtime for one loop
in the worst case down from 30 seconds to 1/2 second.
@bennn
Copy link
Contributor Author

bennn commented Sep 10, 2022

Any suggestions for how to write regression tests? I'm thinking the unit tests for static contracts need a way to check expected output.

@capfredf
Copy link
Member

Any suggestions for how to write regression tests? I'm thinking the unit tests for static contracts need a way to check expected output.

we could extend t/sc in static-contract-conversion-tests so it can take an expected value.

jackfirth added a commit that referenced this pull request Sep 12, 2022
Just touching this file to get Resyntax to analyze it so I can debug why it didn't review #1282 properly.
@jackfirth jackfirth mentioned this pull request Sep 12, 2022
[_ #false]))

(define (group-types-by-elems t->elems ts)
(group-by t->elems ts non-#f-and-equal?))
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here & below, the code is more flexible that it needs to be. It lets t->elems return #f and calls the normal (t->sc _) if that happens.

If we raise an error instead of allowing #f, then we can delete this "group-types" function and one argument from merge-types->scs

@bennn bennn requested a review from capfredf September 14, 2022 19:19
@bennn bennn merged commit 29ea3c1 into racket:master Sep 20, 2022
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.

2 participants