GORM Performance comparison with other ORMS/Tools

[AAlvarez90]

Your Question

@jinzhu I just wanted to show you this: https://github.com/efectn/go-orm-benchmarks It seems that Gorm is allocating a lot and among the slowest orms/tools out there. Is there a way you could take some time to look into some performance optimizations? I also wanted to share with you this article about Generics and Interfaces and how it can slow down the code: https://planetscale.com/blog/generics-can-make-your-go-code-slower In case you may be implementing some generics with interfaces by now, it can even slow things down given the implementation flaws present in Go

The document you expected this should be explained

Expected answer

Up to you to take a look and take action.. As the tool gets super popular is important to keep an eye on allocations/performance and the impact in a garbage collected language like Go..

[pablodz]

Same issue here, some queries just increase consumption to 99% RAM

[a631807682]

We use pgx as driver, we can't be faster than pgx, so I am more concerned about the performance difference in MultiInsert and MultiRead. The following problems can be found:

1. We use pgx/v4/stdlib wihch is slower than https://github.com/jackc/pgx gorm.ConnPool is an interface, so it is possible for us to implement these interfaces through pgx without directly using sql.DB as ConnPool

2. We are executing too many fallbackSetter because we didn't capture the type we wanted to handle. Just like type intand *int is going to be converted to **int and ***int https://github.com/go-gorm/gorm/blob/master/schema/field.go#L960 https://github.com/go-gorm/gorm/blob/master/schema/pool.go#L14

3. The setter in setupValuerAndSetter does a lot of things similar to sql.convertAssignRows. Maybe we can directly convert src type to field type instead of src type to dest type and then to field type.

4. Maybe we can release the connection earlier before executing the database-independent logic.