Results 1 to 8 of 8
  1. #1
    Join Date
    May 2005
    Posts
    30

    Unanswered: Performance Confusion

    Hi,
    Can any of you folks take a minute to tell me why the results of the attached test are weird. I'm trying to come up with a method of allowing my business layer to interact with the data layer - specifically a nice, easy to maintain, but safe method of passing parameters without adversely impacting performance.

    This is only a few of my sketchy ideas so far but I'm stuck because I cannot prove that using OR is slower than a straightforward = because each time I run the test the OR seems to perform better. Even changing the sequence in which the piece work still does alter the OR begin better than =.

    And, of course, as that makes no sense whatsoever I cannto really progress.

    Any thought would be appreciated. I hope I have altered the script enough that you can just run it straight in and see what I'm talking about. I only introduced the transactions to see if any of that stuff my be interfering.

    Thanks.
    Attached Files Attached Files

  2. #2
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Presumably FLOWBOOL and FLOWUSER are UDTs? Anything special about them? Just bit and varchar?

    EDIT - oops - FLOWBOOL is char(1) or similar
    Testimonial:
    pootle flump
    ur codings are working excelent.

  3. #3
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,800
    Provided Answers: 11
    Here are the results from my poor pathetic test box (maybe a PIII)
    Code:
    XML Join    XML Variables OR          Coalesce    =           Dynamic     
    ----------- ------------- ----------- ----------- ----------- ----------- 
    270         200           10          10          10          30
    It pretty much shows what I knew before (openXML is an expensive operation). The main reason queries that use OR tend to be slower is that they have a reduced chance of hitting an index on the table. In this case, the optimizer may be smart enough to check the @pName variable only once per query, instead of once per row in the resultset. This would strip out all of the extra comparisons. Whether that one comparison operation really matters that much, is a separate question. About all you can really say is to try to avoid using openXML in queries, and only use it to populate variables which are used in the queries.

    [EDIT: Nice post, by the way]

  4. #4
    Join Date
    May 2005
    Posts
    30
    damn, sorry about those. Yes char(1) (don't ask!!!) and varchar(20)

  5. #5
    Join Date
    May 2005
    Posts
    30
    Wow, MCrowley, the performance differences you got are completely different than mine - i.e. that the xml route was soooo much slower. My real interest is in why the OR and the = methods don't differ significantly.

  6. #6
    Join Date
    Apr 2006
    Posts
    33
    Note - If you are using a small table and looping a query multiple times it might not give you accurate performance indications...

    If the real table will be larger, indexes will play a more important role than a table small enough to fit in memory. You also need to consider caching of data rows in memory and execution plans...
    David Wiseman
    MCSE, MCSA, MCDBA

    www.wisesoft.co.uk

  7. #7
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,800
    Provided Answers: 11
    They do not differ significantly, because the OR gets its bad reputation when it misses an index. On your table (5 rows), that is not nearly a consideration. Try a test on a table of 10,000 rows or so, but make sure the equals hits the index. Otherwise, you just have two slow queries vying for the worst performance.

  8. #8
    Join Date
    May 2005
    Posts
    30
    Sorry, been away. Thanks for those responses.

    I tried this on a much bigger table and the results were more like what I would have expected (well, some of them were). I'm disappointed, however, because I wanted to create a more clever mechanism of building the search parameters without having such a tight contract between say, C#, code and the database.

    For a 36823 record table the results are a significantly different:

    XML Join: 10953
    XML Variables: 3640
    Or: 3470
    Coalesce: 5483
    =: 16
    Dynamic: 33

    Surprises here, for me (non database person if you haven't guessed ) are that dynamic sql takes second position, 'or' outperforms coalesce and that XML variables are quite performant!?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •