Slow compiling of packages which use autogenerated models

[Nitjsefni7]

We are currently in the process of migrating from sqlboiler to bob. As the result, the time needed for compiling packages which rely on autogenerated code provided by the bob package has significantly increased.

I have used the debug flags for go build command to check the differences between compiling time before the migration (using sqlboiler) and the current state. The package I have used is our private DAL package, which heavily relies on the autogenerated code from bob and previously from sqlboiler. Before each compilation, I have cleared the cache.

I have examined the traces using https://ui.perfetto.dev/.
sqlboiler_trace.json
bob_trace.json

There are few significant differences, that caught my attention:

1. Total time needed for compilation:
   sqlboiler: ~29s
   bob: ~41s

2. Building of the package containing autogenerated code:
   sqlboiler: 3.3s (two packages, one for each schema, 40 tables)
   bob: 12s (2 schemas within a single package, 40 tables)

3. Building of the DAL package itself:
   sqlboiler: 1s
   bob: 7.5s

4. Different package, imported by DAL, which also imports a single struct from bob's autogenerated code (object representing the database table):
   sqlboiler: 50ms
   bob: 2.5s

No doubt bob is superior to sqlboiler, however the long compiling time is something that might be a concern. I wonder have you stumble upon this issue already? Do you see any space for improvements, that could speed up the compiling time?

[stephenafamo]

My best guess is that the slower compile times is due to the heavy use of generics.

While this allows Bob to be more correct and share more code while retaining type safety, generics in Go definitely add to compile times.

For Bob, type safety and runtime speed have always been higher priorities, and the assumption is that the focus should be to generate "Good Go Code", and trust the Go team to maintain fast compile times.

[Nitjsefni7]

For anyone interested in this matter, I have found discussion about I think a similar problem here
golang/go#50438 (comment)

and this issue being considered a main obstacle to resolve
golang/go#56718