[Mono-list] - XslCompiledTransform.Load missing overloads

[daniel]

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  -  Mono-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-list
>>    
>>     
>
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>