Unit of work slower when cache is enabled.

[ralphga]

Describe the bug
Hello! We are trying to optimize our code and is looking at enabling di_Configurations__c.UsePlatformCacheToStoreBindings__c
And we are noticing that the UnitOfWork newInstance is slower when cache is enabled. I might be wrong but it seems that if cache is enabled, it is adding the binding to the cache but not using the cached binding in the succeeding execution?

To Reproduce
I have in total:

• 8 domain bindings
• 26 selector bindings
• 19 service bindings
• 6 unit of working bindings

In a scratch org, running the code below yields these CPU time results:
 fflib_ISObjectUnitOfWork uow = new fflib_SObjectUnitOfWork();

• Disabled cache CPU time: 222 out of 10000
• Enabled cache CPU time (3rd execution): 585 out of 10000

Selector test with 1 id, WHERE ID IN condition
List<XObject> tickets = XObjectSelector.newInstance().selectByIds(new Set<String> { 'XObjectID' });

• Disabled cache CPU time: 254 out of 10000
• Enabled cache Maximum CPU time: 0 out of 10000 --

Expected behavior
Faster execution is our expected result which we found in both Selector and Domain. Unfortunately the UnitOfWork newInstance is slower when cache is enabled.

Screenshots and text of error observed
Unit of work, cache Disabled

Unit of work, cache Enabled (3rd Execution)

Version
yes, we have the latest

[ImJohnMDaniel]

G'day @ralphga. Thanks for bringing this up.

Can you elaborate on how you are using Force-DI to store the instance of the UOW? Are you also using the AT4DX framework? Since the fflib_ISObjectUnitOfWork is not natively stored in the platform cache via Force-DI, I need more code examples of how you are connecting the two frameworks.

Thanks for the help.

[ralphga]

Hello John, I appreciate your work and quick response on this.

Yes, you are right, I’m using AT4DX. Apologies for raising this issue in the wrong repo as I was focusing on the di_PlatformCache.cls

Also, I sent the incorrect line of instantiating unit of work in my code, again I apologize.
Here's how I call it:

fflib_ISObjectUnitOfWork uow = Application.UnitOfWork.newInstance();

Thanks again.

[ImJohnMDaniel]

Thanks @ralphga for the extra info. Should be enough to start investigating. Having said that, given the nuances, I can't promise a quick turnaround.

Another question real quick. Has this behavior been observed in any environment other than a scratch org?

[ImJohnMDaniel]

Also, @ralphg, how many bindings for the UOW factory do you have in your org? And how many total bindings of all types is Force-DI/AT4DX currently configured with?

[ralphga]

No worries @ImJohnMDaniel on the turnaround time :) thank you for checking this out.
I run some test on our UAT environment which is a full sandbox and yes, similar behavior when cache enabled was encountered.

Here are the total current count of bindings:

• ApplicationFactory_DomainBinding__mdt: 114
• ApplicationFactory_SelectorBinding__mdt: 344
• ApplicationFactory_ServiceBinding__mdt: 224
• ApplicationFactory_UnitOfWorkBinding__mdt: 160
• PlatformEvents_Subscription__mdt: 34

[ImJohnMDaniel]

@ralphga thanks for the info.

Just to confirm these numbers. You have 114 domain bindings? You mentioned 8 at the beginning of the thread. You have 344 selector bindings? (You mentioned 26 at the beginning.) 224 service bindings? (19 at the start) And you have 160 UOW bindings (6 at the start).

Am I missing something?

[ralphga]

@ImJohnMDaniel in my initial numbers, those are from a scratch org with just the base package.

The higher numbers is from the prod environment which have much more packages. I thought you were referring to prod environment when you asked for total bindings.

Apologies for the confusion.