A big part of the story is also that asp.net full page caching is active by default - this is most likely what makes the load tests seem so incredibly good.
While you are logged in to the C1 Console you bypass this cache so you are guaranteed to see fresh results, and page caching are instantly flushed if new page content is published, so it is a bit more advanced than vanilla asp.net full page caching. You can completely disable full page caching in web.config. You can also selectively disable caching on page or feature level (the is a C1 Function which does that - or you can use std. asp.net api for it).
Other elements that can account for the good performance is that we utilize multiple cores when constructing a page, executing C1 Functions embedded in the page/template in parallel.
Tip: if you add ?c1mode=perf to a page URL you will get a break down of what took how long on a page - a great way to isolate performance bottle necks.
On memory consumption I'm not sure what the other systems you mention does wrong, but we have been super conservative about dragging in 3rd party assemblies and we always think very very hard before we invite new assemblies inside. This mean that very few dll's live in the ~/bin dir and that probably saves us some memory.
To sum it all up I'd say we think about performance and memory usage as important features and we spend time on these features now and then.
But - try to disable full page caching and I'd expect the stellar performance you see will drop.
While you are logged in to the C1 Console you bypass this cache so you are guaranteed to see fresh results, and page caching are instantly flushed if new page content is published, so it is a bit more advanced than vanilla asp.net full page caching. You can completely disable full page caching in web.config. You can also selectively disable caching on page or feature level (the is a C1 Function which does that - or you can use std. asp.net api for it).
Other elements that can account for the good performance is that we utilize multiple cores when constructing a page, executing C1 Functions embedded in the page/template in parallel.
Tip: if you add ?c1mode=perf to a page URL you will get a break down of what took how long on a page - a great way to isolate performance bottle necks.
On memory consumption I'm not sure what the other systems you mention does wrong, but we have been super conservative about dragging in 3rd party assemblies and we always think very very hard before we invite new assemblies inside. This mean that very few dll's live in the ~/bin dir and that probably saves us some memory.
To sum it all up I'd say we think about performance and memory usage as important features and we spend time on these features now and then.
But - try to disable full page caching and I'd expect the stellar performance you see will drop.