Preprocess sitelet runtime metadata

[Jand42]

On unpacking ws web projects, it would be possible to also union all metadata, trim them (remove expressions, not needed for runtime - except try.ws, so look at web.config setting) and save it in a separate binary to be loaded by runtime.

Advantage:

• Faster sitelet startup, but a bit longer compilation. Getting a freshly built website still could be marginally faster as compiler already has all metadata in deserialized form and runtime will have to decompress/deserialize less.

Disadvantage:

• No hot-swapping WS-built dlls. But this is already not recommended, as .js files are not unpacked on app startup, just by the compiler. So there should be a separate mode for hot-swapping, opting out of preprocessing metadata but also unpacking on app startup (or serving Scripts/Contents from memory).

Also WebSharper.Owin is now looking at all bin dlls, this should not be necessary, for unpacking now in WS4 also assumes that every WS dependency is referenced.

[Jand42]

This could be implemented so that the .wsruntime file containing the metadata can be re-generated by the Sitelet runtime if missing (or fails to deserialize or WebSharperSharedMetadata setting is not as current). This would rely on fix #924 for netcore apps.

Also the timestamp of the .wsruntime file can be compared against the .dlls so that unpacking at startup is done when a dll is newer. This would also enable hot-swapping dlls.

[Jand42]

Unpack functionality needs to be moved to WebSharper.Core, so it can be invoked by both compiler and runtime.

Related concern:

• WebSharperDownloadResources is part of unpack, now could be also turned on by the UseDownloadedResources setting so that turning it on for an already deployed application is possible. (Currently download happens only with compile, so downloaded scripts have to be deployed)

[Jand42]

Related ticket that can be implemented on top of this: #863 with a slight modification: metadata in dll does not necessarily need to contain the Sitelet value location, current reflection-based lookup can be moved to unpack (and stored in .wsruntime only).

[Jand42]

Going with simplest implementations: pre-process and simplify metadata for sitelets during compilation for WebSharper 5.0. Also pass metadata to Offline sitelets generation, do not deserialize again, wasting time.

[Jand42]

@granicz
PR #1194 seemed to decrease sitelet initialization time significantly (on Web.FSharp test project):

before:
WebSharper Information: 0 : Initialized WebSharper in 9.2506124 seconds.

after:
WebSharper Information: 0 : Initialized WebSharper in 0.98145 seconds.

However, sadly this was bc most dependency graph information was dropped by mistake. A quick fix to this increases init time again, but still way less than original:

with dep graph fixed:
WebSharper Information: 0 : Initialized WebSharper in 1.4144954 seconds.

more optimizations needed to achieve better time, there are 2 main paths:

• improve metadata binary de/serialization, gaining both on compilation time and runtime init
• use graph algorithms to compress dependency graphs, only keeping relations between WS.Web.Control types, methods invoked in quotations and Resource nodes (incl IResources and assembly js nodes).

[Jand42]

Sitelet runtime metadata creation/use is included in WebSharper 5.0