Inconsistent performance when constructing QueryFactory about fflib-apex-common HOT 6 CLOSED

Can you share the case number (don't need the contents, but if we talk to salesforce R&D want to be able to reference it). One big thing we found on a recent internal investigation was the amount of time spent sorting fields to get consistent SOQL output is really a killer. It's looking like having deterministic field ordering should be optional (and really, default to off) for the sake of performance - only used when needing to compare the result against a known good value.

Seeing as queryfactory is getting a major uptake in use I can reach out to a couple people on the apex team and see if they have any advice as well - wasting CPU time is just as bad for the platform as it is for us.

Also, a hearty thank you for talking to salesforce, that sounded like a "fun" case to raise.

from fflib-apex-common.

Heh, "fun" would've been my first characterization too :-)

It's Case #12348492 and it's still open -- I'll post any interesting updates if they come along

Interesting about the sorting of the field list -- I'm holding out hope that the Platform Cache is going to buy a lot of performance happiness for situations like this

from fflib-apex-common.

It might, but the use cases are limited since queryfactory is designed to be used with very dynamic queries. We could look into caching results in the per-user platform cache, but how much that's going to help is up in the air. I'd personally rather go beat up salesforce (and ourselves) to get it runtime optimized as much as possible.

from fflib-apex-common.

I have one Known Issue I've gotten filed thus far:

https://success.salesforce.com/issues_view?id=a1p30000000eMoeAAE

This came out of them claiming that we could just solve this lack of call to hashCode() by setting the log filters accordingly. Three weeks later and we have proven that this is not an adequate workaround given that log filter overrides are their own bug farm.

from fflib-apex-common.

At this point, I guess it's time to close out this issue -- The Case with Support has run its course and ended up back where it was when I first opened this issue -- basically stating verbatim the same business about how the log level of "FINEST" causes the underlying implementation of Map/Set to change and disregard the hashCode() implemented in the user class.

Ultimately, this behavior coupled with the bug enumerated in the Known Issue above means that we need to remove any log filter overrides and ensure that we have our user log level set to DEBUG before making any measurements around performance of transactions

For the record, the first case got split into two cases -- the other one is 12550769

from fflib-apex-common.

@agarciaodeian have we shared the performance improvements we made to QueryFactory here yet? cc @capeterson

from fflib-apex-common.