search

mausch / XmlLiteralsTypeProvider

F# type provider implementing compile-time XML literals
Apache License 2.0
5 stars 2 forks source link

RenderTo #14

Open panesofglass opened 10 years ago

panesofglass commented 10 years ago

Would it make sense to build a RenderTo accepting a TextWriter or Stream to improve performance when used as a view engine?

mausch commented 10 years ago

When using XElements to represent HTML in a web app I use a few functions to render: https://github.com/mausch/MiniMVC/blob/master/MiniMVC/X.cs#L174

We could copy those here, but there isn't much performance improvement, in the end it all boils down to building the tree in memory, then rendering it with a XmlWriter writing to a Stream.

To avoid keeping the entire tree in memory we could look into XStreamingElement which is quite different from the rest of Xml.Linq (it doesn't even implement XObject!)

panesofglass commented 10 years ago

Yes, XStreamingElement looks like exactly what I was thinking of, though that would certainly change some things. Most of my uses would be for rendering back into streams from web applications. If I need to serialize to a string for some reason, I could always write to a StringWriter. Thoughts?

mausch commented 10 years ago

For most HTML output it's not much of a problem to keep the entire tree in memory, as the output is usually small. The only time I could justify using XStreamingElement was when I built some item feeds that generated a multi-megabyte XML.

It's an interesting optimization to keep in mind but I wouldn't worry too much about it at this stage.

panesofglass commented 10 years ago

Good to know. I have never tested this; I just recall an interview with, I think, Lou DeJardin about Spark where he mentioned the need to write directly to TextWriter. What you say makes sense though.