Quick vs Hibernate ORM speed

Communities Quick ORM
#1

Where are trying to replace Hibernate ORM with Quick.

We have see some slowness in Quick vs ORM. For example this code that load a list of entities (I know It should be load in one query but we are just testing):

     var ids = [ 6, 45, 6, 45, 18, 46, 6, 38, 45, 38, 6, 18 ];
     ids.each(function(i){
        var tick1 = getTickCount();
        getInstance('BlogCategory').find(i);
        dump("Quick: " & getTickCount() - tick1);

        var tick2 = getTickCount();
        EntityLoadByPk('blog_category', i);
        dump("ORM: " & getTickCount() - tick2);
     });

The result shows like if quick doesn’t cache the loaded entities and Hibernate loads a lot faster:

Captura de pantalla de 2022-05-10 08-52-45

is there something that I can look at to speed up Quick?

#2

We had the same issue. Not only in speed but also memory consumption. Because of that I did a lot of performance testing and even created a github repo so the Ortus people could see the differences.

A few weeks ago the latest Quick release was announced, which is a lot faster and uses less memory, but still a lot slower compared to hibernate. For us it is good enough, unless we want to load A LOT of entities (we tested 3000 in some nested relations and found a factor 10 or more speed difference).
In these cases we better create some array of structs or limit the amount of objects.
In loading individual entities it is really amazing how fast hibernate is performing. It is many times faster than a simple cfml object creation. Things like wirebox is also slowing down object creation ( a little ).
I was thinking how quick could still be faster, but I think it is almost impossible, unless you really change the design, in which you only create some simple proxy object for the current record, and fill the object with new data once you move to the next data. I was wondering what kind of tricks hibernate is performing, knowing that even creating your own simple object with data is already slower than hibernate.
It will certainly help to reduce the number of database calls, so populate your objects in one actions.
In quick there are easy ways to just loop through an array of structs, which is a lot faster. Just use retrievequery() for that. Disadvantage is that you will loose your mappings here, so no encapsulation.
In older hibernate versions I also wrestled with speed issues, but there you can create structs which are named after the properties in your entities.
Quick is easier to learn, but if you really need speed and better encapsulation cborm is still the better choice. It comes at a price though. I already dumped cborm on two projects because of incompatibilities in Lucee. Might be fixed now, but I never looked back.

#3

Thanks for the answer. Our codebase it’s very large with a lot of ORM & plain query and we want to standardize our service layer and Quick is a very good choice. Maybe we use it in some use case and QB for more speed.

For instance, retriveQuery() doesn’t exists in Quick 5.0-beta3. @elpete any alternative for this in Quick5 ?

#4

I just need to add the method name back in. For now you can getQB() for the same effect.

I temporarily removed it to help me decouple the objects. It will be back before the official release.

1 Like