2

Is there any reason or anything I am doing wrong, why RazorEngine is so slow just to parse 100 different templates? I was looking into StringTemplate, and performed two tests to compare, as per below.

    [Test]
    public void TestStringTemplate()
    {
        CsStopwatch stopwatch = new CsStopwatch();
        stopwatch.Start();
        StringBuilder sb = new StringBuilder();

        for (int i = 0; i < 100; i++)
        {
            string template = @"Hello there my name is <Name> <Surname> "  + i;
            TextParseTests.TestModel model = new TextParseTests.TestModel();
            model.Name = "Karl";
            model.Surname = "Cassar";

            Template t = new Template(template);
            t.Add("Name", model.Name);
            t.Add("Surname", model.Surname);

            var result = t.Render();
            sb.AppendLine(result);
        }
        stopwatch.Stop();
        var ms = stopwatch.ElapsedMilliseconds;
        int k = 5;
        //109ms
    }

    [Test]
    public void TestRazorEngine()
    {
        CsStopwatch stopwatch = new CsStopwatch();
        stopwatch.Start();
        StringBuilder sb = new StringBuilder();

        for (int i = 0; i < 100; i++)
        {
            string template = @"Hello there my name is @Model.Name @Model.Surname " + i;
            TextParseTests.TestModel model = new TextParseTests.TestModel();
            model.Name = "Karl";
            model.Surname = "Cassar";


            var result = Razor.Parse(template, model);
            sb.AppendLine(result);
        }
        stopwatch.Stop();
        var ms = stopwatch.ElapsedMilliseconds;
        int k = 5;
        //24000~ ms
    }

The difference is staggering.

  • StringTemplatev4: 109ms
  • RazorEngine 3.3: 24,131ms

That is over 200x slower than StringTemplate! I have a lot of content using the RazorEngine format, and I prefer the syntax for RazorEngine way over StringTemplate. However, this is extremely, extremely slow.

Any ideas if I may be doing anything wrong? Please note that I am using different templates on purpose, as if I use caching for RazorEngine it is way faster (down to 300 - 400ms) but my website has a lot of tiny text which are different, and this is the most 'real-life' test I could do.

Karl Cassar
  • 6,043
  • 10
  • 47
  • 84
  • 1
    Probably because Razor is a much more complicated language. (it has to run a C# parser too) – SLaks Aug 12 '13 at 17:54
  • 1
    Yeah but StringTemplate still does conditions, and expression literals. A much complicated template, for 1000 iterations runs in less than 180ms. Impressive compared to RazorEngine – Karl Cassar Aug 12 '13 at 18:21

1 Answers1

5

Razor.Parse will compile the template every time.

You shouldn't do this. Your application should compile the template once, or whenever the template is changed if the template is being modified whilst the application is running.

Razor.Compile(template, name);

Following this your application should use

Razor.Run(name, model);

Compare the times against Razor.Run not Razor.Parse

Mick
  • 6,527
  • 4
  • 52
  • 67
  • This is quite old, and unfortunately I've since switched to StringTemplate from Razor. Its way more faster to anything I've experienced with RazorEngine. – Karl Cassar Feb 14 '14 at 09:57
  • I think in a performance test you might find StringTemplate does not fare so well against RazorEngine when it is used properly. "Razor.Parse" is an order of magnitude slower than running "Razor.Run". "Razor.Parse" compiles the template, outputs an assembly to the file system, loads the assembly from the file system, instantiates an instance of the compiled template then does what "Razor.Run" does. – Mick Feb 17 '14 at 05:02
  • I've tried this out. I've marked this answer as correct as it really makes a difference. However, this involves having to compile your templates. In my case, these templates are amendable from a custom CMS. StringTemplate, requires no compilation and performs such task still extremely fast. So for my use case, I still think it is actually better now that I've switched. Being marginally faster isn't an issue - being way slower as it was, was. – Karl Cassar Feb 26 '14 at 14:12