Currently XSLT Is faster if you want to process data and more flexible to maintain inside Umbraco. The next best thing is using the NodeFactory in your usercontrol.
I wasn't saying you're wrong I'm just interested to see the results. I'm more inclined to write .NET rather than XSLT (as that's where my skillset lies) but I would love to see someone show me whether or not that's right ;) (although it does beg the question, how do you test :P)
This is my first message here. I’m discovering Umbraco and I’m learning the options of the product. I like what I see so far. Right now I’m programming some controls in .Net. I did take a look at XSLT but since my background is .Net I kind of automatically made the choice for .Net code.
I see there was a question over a year ago asking if .Net or XSLT is faster. I have the same question and I’m wondering if the answers are still valid. If XSLT is still faster I like to know if it is big difference or a more theoretical difference.
I don't know of anyone who has run tests to compare performance between .net and xslt for macros that do the same thing so I'm not aware of any hard data to confirm which is faster. What I can say is that both are very fast. Even on modest servers you'll find macros (xslt or .net) will execute in less than a few hundredths of a second, often in a few milliseconds.
As with any system, you can write macros that perform badly... but that's not an indicaton of a problem with the technology itself.
My advice would be to use .net if you need to (some things can't be done in xslt) or if you prefer it. But don't let performance be the basis for your decision.
For me the fact you can change your XSLT so easily make any performance hit that might exist well worth using XSLT (with the odd helper extension object) where ever possible. Remember XSLT is a templating language so if you are doing much more than rendering stuff out then .net might be the way to go.
I'm with Doug on this one, both are super fast, fast enough that you don't really have to worry about it unless you are building something for NASA.
Using XSLT with some custom .net extensions should be enough to allow you to do 95% of what you might want to do and nicely seperated out the logic (.net) from your content (you xml) and how you render that content (you xslt).
Hmmm. The way I worded my previous post almost sounds as though I recommend .net by default and xslt only if you'd prefer it. As anyone who knows me will realize, *I* tend to think of it the other way... I like xslt a lot so I use it by default unless there's a good reason to use .net.
*whew* glad I got that cleared up :)
Seriously, use whichever you prefer or better fits your needs. When possible, work in your strengths. In other words, use whichever you prefer without worrying about performance; the performance of .net or xslt is not a significant factor as they're both blisteringly fast in umbraco.
I agree with Doug and Peter on this one. I try to use xslt and extensions whenever possible and move to .net if the macro is a bit more complex or when I want more protection of the source. Can't speak to performance issues but I've never had a problem with xslt speed specifically.
I would choose whatever you and your team feel more comfortable with. If you're working on a larger team you may want to allow non-developers the ability to create and modify macros and xslt is much easier to teach than .net.
@slace - looking forward to hearing your wise words and some new umbraco feature that auto-inserts only the xslt extensions in use in the macro rather than defaulting to define them all even when unused ( hint, hint, hint, o mighty coding dude)
Thanks for
your replies so far. For me is a good reason to use C# the option to reuse code
your making. It is also much better readable. Or is there something is should
know about XSLT and do I prove here that it was not a lie when I say I did ‘look’
at XSLT.
Actually Doug it'd be better if a single instance of each XSLT extension was created per request and passed in, that way they can do internal caching making them perform faster.
Hmm I may build that into snapshot :P
But determining which XSLT extensions are required and only adding them would probably add unnecessary overhead into the running of an XSLT.
My rule of thumb is "if you're writing an XSLT of more than 20 lines including markup you're likely doing something wrong [unless you're writing XSLT Search(tm)]".
The power of XSLT lies in XPATH - when done right, those optimized and compiled queries combined with fully cached data is *really* hard to beat performance wise when playing with .NET lists and LINQ.
But as with anything else; if you master a specific tool it's likely it'll be the best one for you.
In my XSLT's, if I don't use all the extra functions that are inside in those exslt libraries (for example: Exslt.ExsltMath)) and remove all the xmlns attributes in the <xsl:stylesheet> at the top of the page, that I don't use, will it make my macro faster? Thus, a faster webpage?
Which is faster... XSLT macro or .NEt User Control..
Seems that there shouldnt be much difference but is there any information about which is faster at rendering or any differences in pulling data ?
Currently XSLT Is faster if you want to process data and more flexible to maintain inside Umbraco. The next best thing is using the NodeFactory in your usercontrol.
How about python macros? Would you know if this is as fast as xslt? I find it faster to work with anyway. :)
@Richard - Do you have anything to back that claim up?
@Slace, Niels told us at the level 2 course. Now you've put me into a position that I have to prove it :-) time for a blogpost (next week)...
I wasn't saying you're wrong I'm just interested to see the results. I'm more inclined to write .NET rather than XSLT (as that's where my skillset lies) but I would love to see someone show me whether or not that's right ;) (although it does beg the question, how do you test :P)
Hello all,
This is my first message here. I’m discovering Umbraco and I’m learning the options of the product. I like what I see so far. Right now I’m programming some controls in .Net. I did take a look at XSLT but since my background is .Net I kind of automatically made the choice for .Net code.
I see there was a question over a year ago asking if .Net or XSLT is faster. I have the same question and I’m wondering if the answers are still valid. If XSLT is still faster I like to know if it is big difference or a more theoretical difference.
Met vriendelijke groet,
Frank Gillebaard.
(PS. Als je dit leest: hoe gaat het Richard?)
I don't know of anyone who has run tests to compare performance between .net and xslt for macros that do the same thing so I'm not aware of any hard data to confirm which is faster. What I can say is that both are very fast. Even on modest servers you'll find macros (xslt or .net) will execute in less than a few hundredths of a second, often in a few milliseconds.
As with any system, you can write macros that perform badly... but that's not an indicaton of a problem with the technology itself.
My advice would be to use .net if you need to (some things can't be done in xslt) or if you prefer it. But don't let performance be the basis for your decision.
cheers,
doug.
For me the fact you can change your XSLT so easily make any performance hit that might exist well worth using XSLT (with the odd helper extension object) where ever possible. Remember XSLT is a templating language so if you are doing much more than rendering stuff out then .net might be the way to go.
I'm with Doug on this one, both are super fast, fast enough that you don't really have to worry about it unless you are building something for NASA.
Using XSLT with some custom .net extensions should be enough to allow you to do 95% of what you might want to do and nicely seperated out the logic (.net) from your content (you xml) and how you render that content (you xslt).
Pete
Hmmm. The way I worded my previous post almost sounds as though I recommend .net by default and xslt only if you'd prefer it. As anyone who knows me will realize, *I* tend to think of it the other way... I like xslt a lot so I use it by default unless there's a good reason to use .net.
*whew* glad I got that cleared up :)
Seriously, use whichever you prefer or better fits your needs. When possible, work in your strengths. In other words, use whichever you prefer without worrying about performance; the performance of .net or xslt is not a significant factor as they're both blisteringly fast in umbraco.
cheers,
doug.
I agree with Doug and Peter on this one. I try to use xslt and extensions whenever possible and move to .net if the macro is a bit more complex or when I want more protection of the source. Can't speak to performance issues but I've never had a problem with xslt speed specifically.
I would choose whatever you and your team feel more comfortable with. If you're working on a larger team you may want to allow non-developers the ability to create and modify macros and xslt is much easier to teach than .net.
-Chris
* Wanders in and wonders if I should voice an opinion :P
Only thing I'll say on performance is that the more XSLT extensions you use the slower your XSLT will become.
I've got a whole series of points on separation of logic which you can hear me ramble about at CG10 :P
@slace - looking forward to hearing your wise words and some new umbraco feature that auto-inserts only the xslt extensions in use in the macro rather than defaulting to define them all even when unused ( hint, hint, hint, o mighty coding dude)
cheers,
doug.
Hi,
Thanks for your replies so far. For me is a good reason to use C# the option to reuse code your making. It is also much better readable. Or is there something is should know about XSLT and do I prove here that it was not a lie when I say I did ‘look’ at XSLT.
Gr Frank
Actually Doug it'd be better if a single instance of each XSLT extension was created per request and passed in, that way they can do internal caching making them perform faster.
Hmm I may build that into snapshot :P
But determining which XSLT extensions are required and only adding them would probably add unnecessary overhead into the running of an XSLT.
My rule of thumb is "if you're writing an XSLT of more than 20 lines including markup you're likely doing something wrong [unless you're writing XSLT Search(tm)]".
The power of XSLT lies in XPATH - when done right, those optimized and compiled queries combined with fully cached data is *really* hard to beat performance wise when playing with .NET lists and LINQ.
But as with anything else; if you master a specific tool it's likely it'll be the best one for you.
I just want to ask something very simple...
In my XSLT's, if I don't use all the extra functions that are inside in those exslt libraries (for example: Exslt.ExsltMath)) and remove all the xmlns attributes in the <xsl:stylesheet> at the top of the page, that I don't use, will it make my macro faster? Thus, a faster webpage?
is working on a reply...