Don’t let CatalogEntryFull slows you down.

Just like any EPiServer products, one of main concern of us when developing Commerce is performance. Why many parts of Commerce can be described as “Good enough”, some parts are just acceptable, and I must admit that there’s area where performance need to be improved to meet customer’s expectation.

We are under an intensive performance improvement process which we try to optimize our code to cut out any slow code we can found. And one thing come to my mind when I investigate the impact of CatalogEntryResponseGroup. Let’s see the dotTrace profile for CatalogEntryFull value: 

You can see how insane CatalogEntryFull can do. It’s more than 4000 call to LoadEntryWorker just to load 9 Entry.

The terrible secret behind CatalogEntryFull is when you use it, Catalog system will try to load everything of the CatalogEntryDto, along with associations and children, recursively. The more complex and related your catalog entry is, the slow CatalogEntryFull becomes.

While we recommend to use new content API:s whenever possible, there are still place where Entry/Entries being used, such as when you call CartHelper.AddToCart method. Be sure to use the minimal ResponseGroup which works for you, instead of throw the full-fledge, big and slow CatalogEntryFull.

TL, DR; you should avoid CatalogEntryFull if you don’t have too. Use it only you absolutely need it. Use most lightweight CatalogEntryResponseGroup enum that do the work for you. You might need to use several enum combined, such as Assets | Inventory, instead of just going for the bad, ugly and slow CatalogEntryFull.