What is the performance footprint when calling resolve on the same dynamic link multiple times?

Question

In DD4T when rendering a component link we use myComponent.GetResolvedUrl(), which a few layers below calls LinkFactory.ResolveLink(component.Id) and subsequently relies on Tridion's sexy Dynamic Linking functionality. If I need to render the same link in multiple places in my view, I would normally store the output from the GetResolvedUrl function in a variable and use that subsequently to avoid doing processing of the same thing multiple times.

My question is, what is the performance footprint if I do call the comp.GetResolvedUrl() function on the same item several times? Is Tridion Dynamic Linking going to be crunching through its algorithm each time (described here [login required]: http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/concept_05ACF7173DCA4790A458CDE2BA33E2CC), or does the object cache play a big role here allowing me to be lazy and call GetResolvedUrl() all I want on the same item without experiencing heavy redundant processing?

Answer 1

I would say the performance impact is the actual link resolving (db lookups, linking resolving logic). Tridion will do this crunching only once if you enable Tridion CD caching for page links and component links.

Remember that the Tridion CD caching is not time based, cached items are flushed when new content is published which might affect the cached data. This makes the Tridion CD cache a good resource for the scenario you describe.

Having this said, of course never solely rely on Tridion caching but design for other caching layers on web application and application server level too.

Answer 2

As usual... it depends :)

Luckily this is really easy to test - just use a timer and resolve the same link 100 times and check the difference between first and subsequent link "resolves".

Do keep in mind that you need to include the "current page ID" in the link, or it won't be cached (because proximity rules may influence the link result). If you specify "tcm:0-0-0" as the source page then the link can't be cached.

I regularly see an elapsed time of 0 or 1 millisecond for a cached link, vs 20-50 ms for a non-cached link. Obviously, take these numbers with a grain of salt as it really depends on your architecture, database performance, etc.