anybody knows which ones works faster ?
+2
A:
Your answer depends on where you load your views pages from.
Templated Helpers have a slight edge because without any view overrides they are manipulating strings behind the scenes to produce html output.
Input Builders load views through embedded resources or through the traditional file system which will always be slightly slower than hardcoded string manipulation.
The code for both is similar and do basically do the same amount of reflection and metadata processing. Without any file or resource loading complications they both run at < 1 ms. With customized template sourcing via embedded resources or file system calls your performance loss will be the same for both.
jfar
2010-04-26 15:00:39
I'd assume most view engines cache the views. I know spark caches compiled versions in memory. I use FubuMVC input conventions (http://geekswithblogs.net/ryanohs/archive/2010/02/24/using-fubumvcrsquos-html-conventions-in-microsoft-mvc.aspx) which also have caching built in so I haven't had any performance issues but I've never done a performance comparison either.
Ryan
2010-04-26 15:46:49
+2
A:
The Embedded Resources of the Input Builders are servered through the WebFormView engine. When your application is set to debug=false in your webconfig the view engine caches the view, so it is only loaded from the assembly once. The real reason why the input builders would be a little bit slower is that they use a master page to reduce the HTML you maintain. The Editor Templates will produce an input for example. The equvilent Input Builder will produce a label, input, and the html 'chrome" around the two so that you can specify it once and have it applied to every form that uses the input builder. The input builders are really for applying a convention for how your forms markup is built and it does it in a way that gives you control but also keeps your html fragments "DRY" (dont repeat yourself).
Like everything there are tradeoffs. For the input builders, you trade off some runtime performance for developer productivity. At the end of the day if you needed to have a super performant form on a public website, your best option would be to server a static html file that posts to an MVC Action.
Eric Hexter
2010-04-30 02:42:49
and if you are using Field.Master for TemplatedHelpers also (like here http://bradwilson.typepad.com/blog/2009/10/aspnet-mvc-2-templates-part-5-master-page-templates.html), than you don't have any difference in speed ?
Omu
2010-04-30 06:01:27
If you were to use the master templates in that scenerio than I think you are talking about equivilent functionality an very similar implementations, since the InputBuilders use the built in WebFormsViewEngine. I would say when push comes to shove, that the built in helps should be faster as they have put more time into the performance. That comes with a trade off because the input builders provide a clean convention api to enrich your model with additional values for say a drop down. You trade some performance for a cleaner extensibility.
Eric Hexter
2010-05-04 13:41:49