Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Barry 99 posts 187 karma points
    Aug 28, 2009 @ 16:56
    Barry
    0

    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 ?

  • Richard Soeteman 4045 posts 12898 karma points MVP 2x
    Aug 28, 2009 @ 17:42
    Richard Soeteman
    1

    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. 

  • Dennis Morgan 11 posts 10 karma points
    Sep 02, 2009 @ 20:32
    Dennis Morgan
    0

    How about python macros? Would you know if this is as fast as xslt? I find it faster to work with anyway. :) 

  • Aaron Powell 1708 posts 3046 karma points c-trib
    Sep 03, 2009 @ 05:33
    Aaron Powell
    1

    @Richard - Do you have anything to back that claim up?

  • Richard Soeteman 4045 posts 12898 karma points MVP 2x
    Sep 03, 2009 @ 12:26
    Richard Soeteman
    1

    @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)...

  • Aaron Powell 1708 posts 3046 karma points c-trib
    Sep 07, 2009 @ 07:31
    Aaron Powell
    0

    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)

  • Frank Gillebaard 3 posts 23 karma points
    Jun 07, 2010 @ 16:42
    Frank Gillebaard
    0

     

    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?)

     

  • Douglas Robar 3570 posts 4711 karma points MVP ∞ admin c-trib
    Jun 08, 2010 @ 13:20
    Douglas Robar
    2

    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.

  • Peter Duncanson 430 posts 1360 karma points c-trib
    Jun 08, 2010 @ 14:07
    Peter Duncanson
    0

    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

  • Douglas Robar 3570 posts 4711 karma points MVP ∞ admin c-trib
    Jun 08, 2010 @ 18:52
    Douglas Robar
    0

    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.

  • Chris Dunn 210 posts 401 karma points
    Jun 08, 2010 @ 20:01
    Chris Dunn
    0

    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

  • Aaron Powell 1708 posts 3046 karma points c-trib
    Jun 09, 2010 @ 00:43
    Aaron Powell
    0

    * 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

  • Douglas Robar 3570 posts 4711 karma points MVP ∞ admin c-trib
    Jun 09, 2010 @ 16:55
    Douglas Robar
    1

    @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.

  • Frank Gillebaard 3 posts 23 karma points
    Jun 10, 2010 @ 16:34
    Frank Gillebaard
    0

    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 

  • Aaron Powell 1708 posts 3046 karma points c-trib
    Jun 11, 2010 @ 00:47
    Aaron Powell
    0

    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.

  • Niels Hartvig 1951 posts 2391 karma points c-trib
    Jun 11, 2010 @ 01:09
    Niels Hartvig
    0

    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.

  • Bill 81 posts 83 karma points
    Jul 30, 2010 @ 20:50
    Bill
    0

    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?

     

Please Sign in or register to post replies

Write your reply to:

Draft