I think this is a dup of #14775. Dave wrote gentypes to simulate vim25/types -- search for vim25 in the golang-dev thread "Compiler performance with a huge project".

Also, this package does 5769 calls to reflect.TypeOf, populating a map:

types.go:       t["WillLoseHAProtection"] = reflect.TypeOf((*WillLoseHAProtection)(nil)).Elem()
types.go:       t["WillLoseHAProtectionFault"] = reflect.TypeOf((*WillLoseHAProtectionFault)(nil)).Elem()
types.go:       t["WillModifyConfigCpuRequirements"] = reflect.TypeOf((*WillModifyConfigCpuRequirements)(nil)).Elem()
types.go:       t["WillModifyConfigCpuRequirementsFault"] = reflect.TypeOf((*WillModifyConfigCpuRequirementsFault)(nil)).Elem()
types.go:       t["WillResetSnapshotDirectory"] = reflect.TypeOf((*WillResetSnapshotDirectory)(nil)).Elem()
types.go:       t["WillResetSnapshotDirectoryFault"] = reflect.TypeOf((*WillResetSnapshotDirectoryFault)(nil)).Elem()
types.go:       t["WinNetBIOSConfigInfo"] = reflect.TypeOf((*WinNetBIOSConfigInfo)(nil)).Elem()
types.go:       t["WipeDiskFault"] = reflect.TypeOf((*WipeDiskFault)(nil)).Elem()
types.go:       t["WipeDiskFaultFault"] = reflect.TypeOf((*WipeDiskFaultFault)(nil)).Elem()
types.go:       t["XmlToCustomizationSpecItem"] = reflect.TypeOf((*XmlToCustomizationSpecItem)(nil)).Elem()
types.go:       t["XmlToCustomizationSpecItemRequestType"] = reflect.TypeOf((*XmlToCustomizationSpecItemRequestType)(nil)).Elem()
types.go:       t["ZeroFillVirtualDiskRequestType"] = reflect.TypeOf((*ZeroFillVirtualDiskRequestType)(nil)).Elem()
types.go:       t["ZeroFillVirtualDisk_Task"] = reflect.TypeOf((*ZeroFillVirtualDisk_Task)(nil)).Elem()

As @randall77 was mentioning the other day, the compiler could inline the reflect.TypeOf calls. (then they could stop autogenerating the Elem part)

@josharian, ah, indeed. I searched the issue tracker for the vmware phrases but didn't find it. Thanks. Closing this one.

Calling reflect.TypeOf at runtime shouldn't impact the time to compile this
package.

On Thu, Aug 25, 2016 at 9:16 AM, Brad Fitzpatrick notifications@github.com
wrote:

Also, this package does 5769 calls to reflect.TypeOf, populating a map:

types.go: t["WillLoseHAProtection"] = reflect.TypeOf((_WillLoseHAProtection)(nil)).Elem()
types.go: t["WillLoseHAProtectionFault"] = reflect.TypeOf((_WillLoseHAProtectionFault)(nil)).Elem()
types.go: t["WillModifyConfigCpuRequirements"] = reflect.TypeOf((_WillModifyConfigCpuRequirements)(nil)).Elem()
types.go: t["WillModifyConfigCpuRequirementsFault"] = reflect.TypeOf((_WillModifyConfigCpuRequirementsFault)(nil)).Elem()
types.go: t["WillResetSnapshotDirectory"] = reflect.TypeOf((_WillResetSnapshotDirectory)(nil)).Elem()
types.go: t["WillResetSnapshotDirectoryFault"] = reflect.TypeOf((_WillResetSnapshotDirectoryFault)(nil)).Elem()
types.go: t["WinNetBIOSConfigInfo"] = reflect.TypeOf((_WinNetBIOSConfigInfo)(nil)).Elem()
types.go: t["WipeDiskFault"] = reflect.TypeOf((_WipeDiskFault)(nil)).Elem()
types.go: t["WipeDiskFaultFault"] = reflect.TypeOf((_WipeDiskFaultFault)(nil)).Elem()
types.go: t["XmlToCustomizationSpecItem"] = reflect.TypeOf((_XmlToCustomizationSpecItem)(nil)).Elem()
types.go: t["XmlToCustomizationSpecItemRequestType"] = reflect.TypeOf((_XmlToCustomizationSpecItemRequestType)(nil)).Elem()
types.go: t["ZeroFillVirtualDiskRequestType"] = reflect.TypeOf((_ZeroFillVirtualDiskRequestType)(nil)).Elem()
types.go: t["ZeroFillVirtualDisk_Task"] = reflect.TypeOf((*ZeroFillVirtualDisk_Task)(nil)).Elem()

As @randall77 https://github.com/randall77 was mentioning the other
day, the compiler could inline the reflect.TypeOf calls. (then they could
stop autogenerating the Elem part)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#16868 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA-IO0RMBnza6ir0vEDiWIAQgKRMXks5qjNDAgaJpZM4Jsi28
.

But setting up those calls does, particularly as compared to emitting static data.

My bug conflated two things I saw. I filed a separate bug for the typeof part.

(TypeOf bug is #16869)