Comments on: Opinionated Input Builders Part 6 – Performance of the builders

By: John Farrell

John Farrell — Sun, 14 Jun 2009 16:12:51 +0000

I’m running this on my local machine with debug enabled and seeing a 400ms duration between just the controller and view rendering.

Thats pretty unacceptable to just render a form.

By: smurf

smurf — Sun, 14 Jun 2009 15:59:30 +0000

the same is true for me

By: erichexter

erichexter — Sun, 14 Jun 2009 12:56:03 +0000

@smurf, There will be a way to extend this and plugin your own DI. I prefer to expose that through some sort of factory method so that this framework does not take a direct dependency on a DI framework and force that on everyone else.. I hate when Open Source Projects do that.

By: erichexter

erichexter — Sun, 14 Jun 2009 12:54:16 +0000

@Haacked, I did set debug=false in the config. But I am using a virtualPathProvider to read partials out of my assembly. So I think it would be good to pull that out and see what the performance looks like. I know there is caching provided by the path provider that is not being handled by my implementation.

@Chad totally agree that the performance issues are solvable and in most cases perform good enough for most projects. The other reason I would suggest sticking with this approach is that as I get this into MvcContrib, we will be optimizing this and as a result solving problems for the community so that as a community we can solve this and provide more efficiency/productivity. I hope we can do this through runtime enhancements rather than through precompilation but if that is what it takes … that is an option.

By: smurf

smurf — Sun, 14 Jun 2009 10:55:39 +0000

eric, take your time.

What was the pain in reusing?

if you don’t provide a string based version, please mind DI to plug it in via a container easely

By: Haacked

Haacked — Sun, 14 Jun 2009 04:48:19 +0000

Eric, did you make sure to do your perf runs NOT in debug mode? When in debug mode, some optimizations in the view engine are turned off, such as caching.

By: erichexter

erichexter — Sat, 13 Jun 2009 20:39:28 +0000

@smurf I do not plan on building a string based version because it has caused me pain trying to reuse it from project to project. I think we could consider it in the future or once this gets into mvccontrib see if someone in the community would be willing to achive the same results with a string based approach.

I will run the test against a page build using the string version of the builders and we can see what its performance footprint looks like.
I think I have a few more posts to get some feedback on the way that the partials are named before I commit this to mvccontrib. Not too much longer….

By: smurf

smurf — Sat, 13 Jun 2009 19:25:55 +0000

thx for that post, i already assumed that the performance will suffer from a lot RenderPartial calls, but with this post it is proofed.

in the CodeCampServer project the InputBuilder approach just build strings, without using partials.

so i would really like it, if you would provide an option to switch between partials and string building and retest the performance with it. (i’m very interested in the results). so people can choose the option which fits best for their needs.

when do you guesstimate to have a first version one can use? (i already extracted the inputbuilders of codecampserver for the next project )