Rendertag, Project Performance, Product Support

Project performance is closely tied to rendertag usage.  Here are some rendertag usage best practices that should be taken into consideration when implementing a project.

Store:Set( key, val )
This is a rendertag that allows storage of variable, but it is unofficial and unsupported. Should projects experience performance or content output issues while using this rendertag, product support may be denied or delayed due to slow priority since it not a product issue but an implementation issue.

Additionally, upon full site publish or multiple users accessing the same Store value may experience a race condition since everyone is trying to write and read from the same variable.  For example, generated link for Page B links to Page A because the link value was read milliseconds before it was updated.

.Elements.GetElement(), .GetPathArray()
A page object get loaded into memory prior to any page info marshaling/inspection call, wide usage in project cause the server to use up memory much quicker.  Since the memory garbage collector in .NET could not keep up with the clean up, server tend to become unresponsive more often.

Another issue with rendertag and this rendertag in particular is caching.  Content retrieve via rendertag get cached, but the cache do not get update notification upon targeted content change, hence rendertag continues to display old content.  Please note, this issue do not occur if rendertag is used within navigation template.

Foreach and Store
Content retrieved within foreach rendertag will experience caching issue.  Content output within foreach rendertag via Store rendertag will experience race condition upon heavy multiple access.