Will add more performance test results today between Fortis, Glass.Mapper and plain Sitecore API for most common operations with Sitecore items. Will probably start from results and then explain them below.

Tests were executed on the same Sitecore master database on 100000 items of same “Content Page” template.

• Get Item – here I have been using SitecoreService.GetItem() for Glass, ItemFactory.Select() for Fortis and Database.GetItem() for Sitecore API.
• Read Field Value – assigning a field value from typed object to variable. Were reading one field per item.
• Render Field – GlassHtml.Editable(item, x => x.Title) for Glass, item.Title.Render() for Fortis and FieldRenderer.Render() for Sitecore API.
• Cast (interface) – Glass.Mapper provides an extension method for Sitecore.Data.Items.Item “.GlassCast()” which converts sitecore item into typed Glass object. Fortis has same functionality within SpawnProvider.FromItem(). In this case I have been converting items to generated model interface INavigation (which is one of base templates of Content Page template). In this case, Glass returns the Castle.Proxy.INavigationProxy object.
• Cast (implementation) – the same as above but converting were done to concrete model type – Navigation.

Basically this chart displays all my concerns about tons of reflection being processed in Glass.Mapper in previous post. But what is interesting here is that casting to interface using proxies works faster than casting to concrete generated model type. One way or another, Fortis works faster and all cases are very close to plain Sitecore API.