Re: [go-nuts] Golang ORM Performances

[Robert Engels]

This is incorrect. Most ORM will efficiently execute the first query with a single SQL statement.  It’s called the N+1 Select problem and it is solvable.  On Dec 21, 2024, at 3:43 AM, Luca Pascali <pascko...@gmail.com> wrote:  In my experience, ORM has a structural flaw, and it cannot be otherwise (as well as a lot of automatic tools) Using ORM you are driven to write queries like (pseudo go code) objects := Table.filter(some rules) for o := range objects {     if o.field == 5 {        sub := Table2.filter(some other rules)    } } this cannot be optimized a lot by compiler or ORM engine, because queries are separated. So having 10k elements on first query can bring up to 10k subqueries and the (almost) only optimization that the engine can operate is to cache queries result to choose if using an old result (can bring to other issues like memory usage or data retention) or ask to the db (lots, lots, lots of queries) If you manage to reduce 10k automatically generated queries to just 1 handcraft query, you can save hundreds of seconds of execution time. Sorry for stating the obvious. Another aspect that magnifies the problem is that ORM engines creates SQL code that must be parsed by the db server, and this time is definetly not zero. And not all db servers have the possibility to precompile queries. Again the obvious: 1ms over 1 query is not a problem. 1ms over 10k queries takes 10 seconds (plus the execution time, plus the parsing time to build object representation, plus ... ). So ORM can be the wrong choice,but If you don't have a complex db structure (this means a few connected tables) and/or you can use some sort of advanced merges where you can specify the projection in the orm itlself (that's something like writing a raw query) ORM is a fantastic abstraction, because it allows you to write simpler code. In conclusion, it is not ORM that is slow. Sometimes it is just not the right tool. If you need some simple access proceed with ORM. If you need something more complex, optimize the code to reduce db access to the essential (prefetch as much as you can) and write your own queries. In that case sqlc is perfect My 2¢ PSK On Fri, Dec 20, 2024 at 6:54 PM Kerem Üllenoğlu <kerem.ul...@gmail.com> wrote: Hey, I keep hearing ORMs - especially GORM - is slow. But I have never felted like it was slow and used in a couple of projects now. Is there a good article you recommend reading about ORMs in Go - especially GORM - being slow? Sorry, my reply is not actually an answer to the original question. But I am really curious about it now. Is it really important, really slow? Thanks, Kerem -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAJNBTxKjFUr-XYU4qC%3DRb6mvFmhQuRQ%2BmiA%3DyFxd6bypnCzLkg%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/437544A3-356C-4536-AE3B-7E9EC8126AF7%40ix.netcom.com.