Use Razor caching to drastically improve performance.

[matthid]

The speed of the API reference generation (and possibly some other things) can be improved drastically by using razor caching (https://razorengine.codeplex.com/wikipage?title=Quick%20Start%20Guide).

In my case I could reduce the time to produce the docs from 600 to 21 secs!
The first two commits improve the error messages (second is a bugfix).

Maybe you should not merge this patch and instead rewrite/remove the RazorRender class to only use caching (ie. currently the class is designed around the ProcessFile function, and my extensions are currently a bit error prone), and do the generation it in parallel again.

Note: The ProcessDirectory function in FSharp.Literate could also benefit from this when ProcessFileCache is used (and CompileTemplate is called at least once).

[forki]

Wow this sounds like a massive improvement.
Since I'm only temporarily maintainer I don't think we should rewrite. But using cache seems like something I could merge

[forki]

Btw AFAIK the long term strategy is to get rid of razor if possible.

[ovatsus]

Even if eventually want to get rid of razor I would merge and publish a new version with this. It's a great improvement

[forki]

Yes that's what I think, too. Will look at it and try to release.
On Sep 29, 2014 1:32 PM, "Gustavo Guerra" notifications@github.com wrote:

Even if eventually want to get rid of razor I would merge and publish a
new version with this. It's a great improvement

—
Reply to this email directly or view it on GitHub
#202 (comment)
.

[matthid]

Why get rid of razor? I did like it, and it is actually very fast :)

I'm not sure why the build would fail, because I use custom solution files (removed paket) and custom deps (custom RazorEngine that works on mono). It is hard for me to run the unit tests locally. But if you look into it I guess I can ignore it for now?

[matthid]

Sorry it seems like I was a little bit too fast :(.

[forki]

no problem. Just tell me when it's ready to merge

[forki]

could you please remove this dead code. thanks

[matthid]

The build is still failing because I used a newer version of RazorEngine, I don't know if the latest nuget version is enough, but could you try updating RazorEngine to the latest nuget version anyway?

[forki]

try the following:

• modify https://github.com/tpetricek/FSharp.Formatting/blob/master/paket.dependencies#L6
• run .paket/paket.exe update (if it doesn exist run the bootstapper)
• this should update the paket.lock file
• commit lock file and dependencies file and push it

[matthid]

I tried that, but I was not able to make it work. I think the new versions are only available for net4.5 and this solution is still 4.0.

But this is an issue for another time, I have added a (rather dirty) workaround for now.

The rewriting of the RazorRender is now also done, so I guess this can be tested/merged? However to leverage this speed for *.md files, one would have to rewrite the ProcessDirectory logic in a way that it reuses a RazorRender instance. I don't need this as I have only a few of those.

Note: It is now actually even faster than written in the first post (15 secs).

[forki]

Oh right. They moved to 4.5

[matthid]

Is there a discussion/faq why you want to move away from razor? Razor seems like a perfect fit.

[forki]

thanks to the support by @jeffhandley it's released in 2.4.26. awesome!

[forki]

why you want to move away from razor?

AFAIK mostly because of xplat. We don't get it to work in the downstream projects.
#188

[forki]

already using it in Paket - see fsprojects/Paket@1e824af

time for docs form 18 seconds down to 4. That's awesome.

Now the 10s for the md files seems like way too much ;-)

[matthid]

Yeah I'm using this on mono actually...
But I had to bundle my own RazorEngine.dll, which is a bit of a pain.

[forki]

oh that's interesting.
we could replace the nuget package and just bundle your build.

[matthid]

See matthid/RazorEngine@2bebf75 for details.

Basically what I do is use this static field to replace the references completely with my own list:

if isMono then
    // Workaround compiler errors in Razor-ViewEngine
    DirectCompilerServiceBase.EditLoadedAssemblyList <- new System.Func<IEnumerable<string>, IEnumerable<string>>(fun loadedList ->
        // We replace the list and add required items manually as mcs doesn't like duplicates...
        let getItem name =
            loadedList |> Seq.find (fun l -> l.Contains name)
        [ (if isMono then "/usr/lib64/mono/gac/FSharp.Core/4.3.1.0__b03f5f7f11d50a3a/FSharp.Core.dll" else "FSharp.Core") 
          getItem "FSharp.Compiler.Service"
          Path.GetFullPath @".nuget/Build/Microsoft.AspNet.Razor/lib/net45/System.Web.Razor.dll"
          getItem "RazorEngine"
          getItem "FSharp.Literate"
          getItem "FSharp.CodeFormat"
          getItem "FSharp.MetadataFormat"
           ] |> List.toSeq
        )

[forki]

do you see any chance to get this back into razor?
(and to get the team release a 4.0 version?)

[matthid]

I could try, but I don't think they would merge these changes, that's definitely not the way it's supposed to be done :).

[forki]

true but it's an outdated package and they do not really care about this anymore, right?

I mean they don't support 4.0 any more.

[forki]

After thinking about this:
I think we should bundle your dll and remove the nuget dependency.

[matthid]

Some notes to my patches:
Watch out that the current RazorRender type is a bit weird (in fact you can use the same instance in multiple threads but not multiple instances at the same time!), I think the best way to fix this is to call the methods on the TemplateService instance directly instead of using the static Razor type. Maybe I submit another pull request when I find some time for it.

This will most likely introduce a whole range of bugs when someone tries to generate API docs and *.md files in parallel.

[forki]

Maybe I submit another pull request when I find some time for it.

that would be awesome ;-)

2014-09-30 14:02 GMT+02:00 matthid notifications@github.com:

Some notes to my patches:
Watch out that the current RazorRender type is a bit weird (in fact you
can use the same instance in multiple threads but not multiple instances at
the same time!), I think the best way to fix this is to call the methods on
the TemplateService instance directly instead of using the static Razor
type. Maybe I submit another pull request when I find some time for it.

This will most likely introduce a whole range of bugs when someone tries
to generate API docs and *.md files in parallel.

—
Reply to this email directly or view it on GitHub
#202 (comment)
.