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.
