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
The compiler now supports an indexed data format for package export data that enables efficient random-access of package data. We already use this to implement lazy expansion of declarations and inline bodies, but we still currently fully expand types whenever they're referenced. I expect in larger projects that a lot of deeply nested details are never needed and we could avoid reading that data into memory.
I think the steps are largely:
Hide remaining Type fields behind setter/getter methods.
Create a new TSTUB Type with a way to register an expander function that rewrites the Type into a real Go type.
Add a Type.expand method that checks for Etype==TSTUB and calls the expander function.
Insert calls to expand() at the top of every(?) public Type method.
Update iimport.go to create TSTUB types instead of normal types.
Another useful (but non-critical) step would be to review the Type API and try to prune/simplify unnecessary methods. This would reduce how many places we need to instrument with expand calls.
The text was updated successfully, but these errors were encountered:
This reduces the API surface of Type slightly (for #25056), but also
makes it more consistent with the reflect and go/types APIs.
Passes toolstash-check.
Change-Id: Ief9a8eb461ae6e88895f347e2a1b7b8a62423222
Reviewed-on: https://go-review.googlesource.com/109138
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The compiler now supports an indexed data format for package export data that enables efficient random-access of package data. We already use this to implement lazy expansion of declarations and inline bodies, but we still currently fully expand types whenever they're referenced. I expect in larger projects that a lot of deeply nested details are never needed and we could avoid reading that data into memory.
I think the steps are largely:
Type.expand
method that checks for Etype==TSTUB and calls the expander function.expand()
at the top of every(?) public Type method.Another useful (but non-critical) step would be to review the Type API and try to prune/simplify unnecessary methods. This would reduce how many places we need to instrument with
expand
calls.The text was updated successfully, but these errors were encountered: