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

memoize more type properties #16320

Merged
merged 4 commits into from
May 13, 2016
Merged

memoize more type properties #16320

merged 4 commits into from
May 13, 2016

Conversation

vtjnash
Copy link
Sponsor Member

@vtjnash vtjnash commented May 11, 2016

type properties are accessed heavily by subtyping and intersection, so it's generally worthwhile to memoize them upon construction.

@carnaval I think you had separately observed this during profiling? Currently, I've also left in the old code paths and use it verify that the cached value is correct when using a debug build.

@carnaval
Copy link
Contributor

yes. I've seen jl_has_typevar show up as a hotspot in perf regularly while doing other things. cool :)

@@ -110,14 +120,17 @@ static int jl_has_typevars__(jl_value_t *v, int incl_wildcard, jl_value_t **p, s
for(i=0; i < l; i++) {
jl_value_t *elt = jl_svecref(t, i);
if (elt != v) {
if (jl_has_typevars__(elt, incl_wildcard, p, np))
if (jl_has_typevars__(elt, incl_wildcard, p, np)) {
if (expect > 0) assert(expect);
Copy link
Sponsor Member

Choose a reason for hiding this comment

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

Doesn't this condition make the assert a no-op?

has-typevars is called pretty heavily during intersection and subtyping
so it can be a hot-path

also fix jl_new_type_constructor to stop mutating (aka corrupting)
the immutable TypeVars it is given as a parameter
corrupt them before instead :)
when it's less likely someone is looking

fix #12238
fix #16301
have lowering emit the correct TypeVar expression instead of fixing it
in the TypeConstructor constructor
have lowering emit the correct TypeVar expression
instead of fixing it in the DataType constructor
@JeffBezanson
Copy link
Sponsor Member

LGTM. Looks like some commits should be squashed.

@StefanKarpinski
Copy link
Sponsor Member

Fortunately, that's now easy to do in GitHub so you can actually just merge this if you want.

@vtjnash vtjnash merged commit 0ffba40 into master May 13, 2016
@vtjnash vtjnash deleted the jn/memoize-dt branch May 13, 2016 18:17
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