So, your application is crashing and it is crashing in?the?bad way. After spending hours of debugging and trying different things you figured out that this is this Xslt stylesheet that causes all the problems. How come? XslCompiledTransform is a compiler. It’s a bit different from C# or VB.NET compilers because it runs at runtime but the result of the compilation is basically the same – IL (Intermediate Language) code. One of disadvantages of running compilation at runtime is that compilation issues may have impact on the running application. In the “offline” scenario compiler would just return an error (the one I hate the most is “Internal Compiler Error” – still it will not affect my app at runtime ?? at worst there is no app). So, compilation may be one source of problems. The other source of problems can be the IL code the stylesheet was compiled to. Here there is not much difference between code generated from Xslt, C# or VB. In any case it is easy to write a program that compiles correctly but misbehaves at runtime (bugs anyone?). Let’s take a look at two most common unexpected exceptions you may hit when working with XslCompiledTransform and ways to resolve them.
日期: 2014 年 7 月 22 日
《高效 XML》第4部分 Let me project this (Xml file) for you
Xml is ubiquitous. No doubt about it. It is being used almost everywhere and almost by everyone. This includes places where huge amounts of data are being processed. This means xml files (or streams) used there are also huge. And the bigger the Xml file the harder it is to process. The two biggest problems are:
- You need to query the document with a couple of XPath expressions or transform it with an Xslt file but the document is too big to be even loaded (the rule of thumb is that an Xml document needs up to 5 times memory of its size on the disk). When you try to load the document you get OutOfMemoryException and that’s about where your Xml processing ends.
- You are able to load the document but all the queries or transformations are sloooow (and I assume it’s not because the queries or Xslt stylesheets are poorly written – if you are not sure see Effective Xml Part 3)
《高效 XML》第3部分 Didn’t you say XslCompiledTransform was fast?
“XslCompiledTransform is fast.”
“Really?”
“Yeah, XslCompiledTransform is fast… if used correctly.”
Indeed, depending on how you use XslCompiledTransform API your transformations can be really fast or not-that-fast (to say the least). The key to understanding where this difference comes from is to understan what XslCompiledTransform.Load() method actually does. The name of the method indicates that it is just used to load Xslt stylesheets. In reality the method does much more than this. It not only loads the Xslt stylesheet but it also compiles it to IL (Intermediate Language). Yes, after the stylesheet has been “loaded” somewhere there in memory is the real code built based on the provided stylesheet. Generating this code (i.e. “loading” the stylesheet) is costly but it allows for fast transformations – when you start a transformation in your app it no longer deals with the stylesheet, it just invokes the code the Xslt stylesheet was compiled to.
继续阅读《高效 XML》第3部分 Didn’t you say XslCompiledTransform was fast?
《高效XML》第2部分 How to kill the performance of an app with XPath…
XPath expressions are pretty flexible. This flexibility allows for very creative ways of using XPath. Unfortunately some of them are suboptimal and cause bad performance of apps. This is especially visible in Xslt transformations where stylesheets contains tens if not hundreds of XPath expressions. Here is the list of the most common bad practices (or even anti-patterns) I have seen:
继续阅读《高效XML》第2部分 How to kill the performance of an app with XPath…