Thats a shame. It appears from our testing that non compiled xslt is an order of magnitude slower then the compiled version. Which for our purposes is to slow.
I see from the msdn documentation that loading by type was added in .net 2.0 SP1. So it wasn't in .net 2.0. Which explains why it is missing from mono 2.0 Even if you can't make a compatible type loading method. Is it possible to make your own non compatible xslt compiler in order to get the speed boost. IE the point of XslCompiledTransform is to compile the xslt into MSIL, this will then execute much faster then a XSLT interpreter. I guess the question is how can you implement a class with 'Compiled' in the name using an interpreter. It's just plain misleading. If you can't make do a 'Compiled' transform then why pretend? XslCompiledTransform should be maked as not implemented/ throw a not implemented exception rather then pretend its a compiled transform when its actually an interpreter. As a user if I wanted an interpreted transform I would have used XslTransform. I would rather its was obvious that mono didn't have a compiled transform then that it appeared to all the world to have one but actually didn't. OK so imagine that mono had implemented StringBuilder using normal string concatenation. Sure it would correctly add strings together but it wouldn't do the thing that people use it for, That is to provide an faster more efficient method of adding strings together. Its the same with XslCompiledTransform. People use XslCompiledTransform because its faster, because its 'compiled'. That is its whole reason for it existing, thats the reason why Microsoft added it rather then just sticking with the existing XslTransform. If you had a XSLT Compiler you could have a fastest XSLT transformer in linux. Our testing to date puts the .net implementation of XslCompiledTransform significantly faster then any other method of performing XSLT transforms on windows. It would give mono bragging rights as well as provide a compelling reason for people doing xslt on linux to use mono. Thats my 2 cents worth. Sincerely, Daniel Atsushi Eno wrote: > NET XslCompiledTransform has horrible design choice that there is *no* > public API > exposed to make compiled XSLT implementable. There is no choice for us > to implement > it at least from public documentation. We won't support it beyond any > wrapper. > > (I feel almost no need to add this comment, but: loading stylesheet by > compiled type is > newer stuff than we have finished 2.0 API. Besides/anyways I don't > really care about tiny, > cosmetic, minor API missings like other API lands.) > > Atsushi Eno > > On 2009/09/24 14:50, Daniel Hughes wrote: > >> XslCompiledTransform.Load appears to only have 6 overloads where as >> .net has 8. The two missing overloads are for loading an already >> compiled transform from a type. These are the overloads I need. When I >> started investigating this I also recognized that the transform on >> mono appears to be a lot slow then it should be..... >> >> I have a horrible thought that XslCompiledTransfrom in mono is just a >> wrapper for XslTransfrom and so it not compiled at all... so none of >> the speed improvement are available. >> >> Please tell me this is not the case and that I am just doing something >> wrong. XslCompiledTransfrom is a .net 2.0 libary I had heard that mono >> had a complete implementation of .net 2.0. >> >> Cheers, >> Daniel Hughes >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Mono-list maillist - [email protected] >> http://lists.ximian.com/mailman/listinfo/mono-list >> >> > > _______________________________________________ > Mono-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list > > _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
