Performance comparisons/benchmarks?

[naasking]

Having recently discovered DotVVM, I'm curious if there are any benchmarks comparing MVC-type solutions with the more component-oriented approach DotVVM takes. I have a largish, old and slow web forms application that I've been considering porting to .net core 2 MVC for the performance and productivity improvements, but DotVVM would make a much easier transition with what looks like many of the same productivity benefits. I don't have a good basis from which to compare the performance though, and there isn't much discussion of this point that I've seen online.

I came across the "performance report" link, but it doesn't seem to load at this time. Any general guidelines for making this kind of choice would be very helpful for people in my position!

[exyi]

No we don't have DotVVM vs MVC comparison for a few reasons:

• Noone wanted to write a significantly complicated application in both DotVVM and MVC
• It really depends how much do you want to optimize the page and on the workload. If you are looking to write performance-first, MVC is going to be faster, there is no doubt about it. However, if you'd like to use the fancy Html helpers (EditorFor and friends) I'd bet for DotVVM (last time I checked it was painfully slow).

If you are worried about performance, I'd suggest you to write a simple test, that will match your workload and measure. I think that the workload type is really important aspect and as far as I know in our applications DotVVM was never a bottleneck (thank you, EntityFramework ;) )

By the way, if you'd measure that DotVVM is significantly slower than MVC in some test, I'd help if you'd share it with us.

The performance report you were looking for was just a table of dotvvm tests, there is no direct MVC comparison. We use it for tracking regressions.

[naasking]

Thanks for the update. I was just thinking of a standard large grid-type test to measure the overhead of pages with lots of controls, which I believe would be the worst-case for DotVVM if I understand correctly. I expect MVC's new tag-helpers use those same combinators, but I would be surprised if they didn't optimize them somewhat.

Part of the business case I'll be making is significant reductions in page load time across many employees, so performance is important to make the savings costs worth the porting effort. This is why I'll be using Dapper instead of EF. The development time savings due to the similarity between the web forms and DotVVM could shift this equation significantly though, as long as the overhead isn't high.

I suppose I'll try some sample ports of existing pages and see how it behaves. Thanks!

[glester]

Hi @naasking I know is an old thread, but did you complete the performance test?. We are running a legacy app with web forms and needs to be migrated, DotVVM would be the framework with lesser effort, but we are wondering about the performance gain (main issue with the current app). Thanks.

[tomasherceg]

@glester Unfortunately, we haven't made any reasonable real-world comparisons between DotVVM and MVC. We can provide some "typical" pages and compare the performance - for example, a GridView with 100 rows, or a form with validation and 20 fields, or something like that.

However, I expect that most of the time will be spent with communication with the database, and so the overall difference between DotVVM and MVC will be quite small. Both MVC and DotVVM are doing just in-memory operations. DotVVM will be a little slower as it builds the control tree and then renders it, while MVC "only concatenates strings". But when the app calls database or some external API, it isn't such a big deal.

I can try to make some performance comparison - not sure how useful it will be, but at least we can try.

[tomasherceg]

@glester I've slightly updated our benchmark repo, and run a test of two DotVVM pages that involve a bunch of commonly used components including Repeater, GridView and others. There is no connection to the database - everything it does happens in memory.

Here are the results - in general, handling a GET or postback request takes ~1ms (single thread, Intel i7 6700 3.4GHz, Windows 10 machine):

Method	Url	Mean	Error	StdDev	Median	Op/s	Total CPU Time	Kernel CPU Time	User CPU Time
Get	/	751.5 us	16.33 us	54.17 us	726.5 us	1,330.6	118.566787406147	5.31796408904259	113.248823317104
Get	/real-world-scenario	1,203.1 us	16.00 us	51.96 us	1,188.1 us	831.2	112.537122714607	4.37873074745893	108.158391967148

Method	Url	SerializedViewModel	Mean	Error	StdDev	Median	Op/s	Total CPU Time	Kernel CPU Time	User CPU Time
Postback	/		1.292 ms	0.0123 ms	0.0403 ms	1.277 ms	773.9	118.602001063845	3.79511736284061	114.806883701004
Postback	/real-world-scenario	realworldscenario	1.173 ms	0.0147 ms	0.0480 ms	1.159 ms	852.4	115.762295788046	3.36195888965282	112.400336898393

I am sure that we can get better in this - it was run on .NET Core 2.1, maybe 3.1 will give use some perf benefits for free. However, I still think that the bottleneck will be more at the database level.

Here is how you can run the benchmarks yourself:

1. Clone the https://github.com/riganti/dotvvm-benchmarks repo

2. Be sure to init and update submodules:

   git submodule init
   git submodule update

3. Open the solution in Visual Studio.

4. Switch to the Release mode.

5. In the properties of the DotVVM.Benchmarks project, on the Build tab, define the following Conditional compilation symbols:

RUN_perf_samples

This will run the default.dothtml and realWorldSample.dothtml in the WebApp/Views directory.

6. Run the project without the debugger (using Ctrl-F5) and wait for the results. There should be two tables produced - the first shows the results for HTTP GET requests to the DotVVM pages, the second shows the results for postbacks (the test just posts back the viewmodel it got from the server without any changes).

default.dothtml is a simple page with a 100 textboxes and buttons. realWorkSample.dothtml is a page that shows a bunch of different controls (including Repeater and GridView) and quite a lot of binding expressions. The viewmodel is also not very simple - it includes nested collections of objects to try out the serialization logic.

The pages are not connected to the database, so this benchmark tests only the performance of DotVVM itself - rendering controls, handling viewmodel serialization and deserialization and so on.

You can add more pages in the WebApp folder - they'll be included automatically to the test suite.