XSLT and XMLDocument Data Type & # 8594; cyclic navigation through nodes using foreach & # 8594; add to Literal Control

Question

I have a question regarding styling XML in C # using the .NET framework. I am working on a website on which 99% of its data is stored as XML. Quite often, I stick with either using XSLT to convert this XML, or reading XML into an XMLDocument data type, parsing it using XPATH, and basically adding output to the Literal server controls throughout the page to process the display. I have the feeling that the latter is much more expensive in terms of memory, since I read XML in the form of data and iterate over nodes using foreach statements and other logical operators. The only reason I usually do this is that I’m much more comfortable doing it, and because I am by no means an XSL guru, this is the only way I can achieve what I need to do. I guess I wanted to know if anyone knows how much more expensive he does it this way? And what factors can influence this, besides the xml size that I am viewing. Thank you in advance.

Answer 1

It was previously shown, as in the classic book of John Bentley , that a bad algorithm implemented in Assembler runs many thousands of times slower than a good algorithm implemented in Basic .

Therefore, it is simply incorrect to say that "Technology A is faster than Technology B".

As far as memory consumption is concerned, it largely depends on the size of the XML document (s). Both XmlDocument and a typical XSLT 1.0 or 2.0 processor create a representation of the complete XML document in memory, so working with XML documents with several gigabytes is problematic in both cases.

XSLT 3.0 (still in the status of a working draft) has that allows you to process an XML document in streaming mode if the XPath expressions used in the conversion adhere to certain restrictions.

I find it useful to consider a set of indicators with only one .

XSLT is a language designed specifically for processing tree structures and, as such, offers valuable features not found in other languages. Two examples are patterns and pattern matching.

Using patterns and pattern matching, a declarative transformation can be expressed . The code is much simpler, shorter, easier to understand and maintain, extensible. Writing XSLT code can usually be done in a few minutes compared to many hours of procedural coding using spaghetti in the procedural language.

Debugging a program in a functional language and even proving correctness is much simpler because the variables are immutable.

For the same reason, there are much greater opportunities for very aggressive optimization with the XSLT processor .

Finally, let me repeat the statement made otherwise by @dash's good answer:

xslt can effectively be HTML output.

On the other hand, with 2 especially, you then lose out on many of the huge features asp.net has to offer, from web forms via MVC. Given that you end up wanting to populate the asp.net server as you do, good, because otherwise you are running xslt only to get the values

Actually, there is an XSLT writing style where there is a strict and clean separation between content and processing (I call this filling in the spaces pattern).

See for example my answer to this question .

Here are some of the benefits of developing an XSLT application with this approach :

• This code can fill in any rendering document (the path is passed as an external parameter) using data from any data document (again, the path is passed as an external parameter). Thus, it becomes possible to create different outputs / formats filled with various data.

• Placeholders ( gen:data elements), which should be replaced by "live content", can have different formats and semantics - no restrictions for one imagination.

• Editors (non-XSLT experts) can work on one or more rendering documents independently of each other and from XSLT developers.

• A higher degree of reuse, flexibility and maintainability has been achieved.

To summarize : the approach of transforming XML with a procedural language based on the DOM, although possible, is more expensive in terms of development resources and leads to lower quality in terms of code complexity, maintainability and extensibility.

Answer 2

Xslt is working on the same principle; it loads it into the DOM (although this is usually not an XmlDocument - there is a read-only XPathDocument read-only model) and executes xpath expressions (ultimately iterates over the nodes).

Poorly written xslt can be slow, and poorly written C # can be slow. To find out which is faster, you need to profile, noting that it is also possible to simply improve your current code (no matter which one).

Answer 3

In addition to Marc, answer, there are a few more things to think about;

• Xslt files can be edited regardless of code recompilation. I worked on a similar system with what you are describing, and the ability to deploy transformations regardless of code changes was useful; the need to recompile and redeploy all binary files was a more difficult task than deploying a single xslt.

• Xslt to HTML can be much cleaner than a combination of XML parsing, literals, and lots of code for setting literals, etc. xslt can effectively be HTML output.

On the other hand, especially with 2, you lose many of the great features asp.net can offer from web forms via MVC. Given that you ultimately want to populate the asp.net server element, the way you do this is good, because otherwise you use xslt to get the values ​​- in fact it is not xslt (which converts XML from one structure to other).

In terms of performance, you're right, XML size is important. If you have 200 users, and each of them downloads an XML document of 10 MB in size, and they do it at about the same time, then you can see that the overhead is just data. If the same XML document, download it once. In fact, cache conversion or processing results, if possible.

Xslt handling is mostly facilitated. Situations when this is wrong is when xslt uses external functions or is very recursive, creating large output documents.

However, sometimes DOM-style processing is much simpler than xslt, because you can pass variables more easily, you can do more processing using .Net BCL functions, etc. etc. in this case, it is worth using XMLDocument and C # code just because it is simpler.

So it really depends.

Remember that you should always try something and then profile it if you suspect that it is ineffective. This will help you figure out what was really worth it. Sometimes this is the only way to decide if something is "best."