none
IComparer vs Generic IComparer RRS feed

  • Question

  • Hello,

    Which one is better at performance?

    Thanks

       class SortYearAscending : IComparer
        {
            public int Compare(object x, object y)
            {
                Person P1 = (Person)x;
                Person P2 = (Person)y;
    
                if (P1.Year > P2.Year)
                    return 1;
                else if (P1.Year < P2.Year)
                    return -1;
                else return 0; 
            }
        }

    And

        class SortYearAscending : IComparer<Person>
        {
            public int Compare(Person P1,Person P2)
            {
                if (P1.Year > P2.Year)
                    return 1;
                else if (P1.Year < P2.Year)
                    return -1;
                else return 0; 
            }
        }


    • Edited by Arash_89 Tuesday, January 28, 2020 8:25 AM
    Monday, January 27, 2020 9:44 AM

All replies

  • The second version as there is no conversion which is done on the first version from object to Person. 

    Please remember to mark the replies as answers if they help and unmarked them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.

    NuGet BaseConnectionLibrary for database connections.

    StackOverFlow
    profile for Karen Payne on Stack Exchange

    Monday, January 27, 2020 10:34 AM
    Moderator
  • Yes, but which one is better at performance?

    Monday, January 27, 2020 11:11 AM
  • The second one as the logic in both are exactly the same so performance on the first will be less than the second as the second is strongly type thus no conversion means more efficient than the first.

    In the second

    class SortYearAscending : IComparer<Person>

    Means only Person type may be used while the first any class can be used so this means that the first is prone to error while the second is not.

    Bottom line is anytime a method is strongly type it will perform better than the one which is not.


    Please remember to mark the replies as answers if they help and unmarked them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.

    NuGet BaseConnectionLibrary for database connections.

    StackOverFlow
    profile for Karen Payne on Stack Exchange

    Monday, January 27, 2020 11:16 AM
    Moderator
  • Ofcourse the second one as it knows at compile time that which implementation to be called (i.e. Person) while in the first one the base object is being used and will require polymorphic-ally identify at run time the actual type of the object and then perform the execution based on that.

    [If a post helps to resolve your issue, please click the "Mark as Answer" of that post or click Answered"Vote as helpful" button of that post. By marking a post as Answered or Helpful, you help others find the answer faster. ]


    Blog | LinkedIn | Stack Overflow | Facebook
    profile for Ehsan Sajjad on Stack Exchange, a network of free, community-driven Q&A sites


    Monday, January 27, 2020 11:31 AM
  • There seems to be issue that you do not use P2 at all in comparison so I would fix that first, then think of performance. The later will perform better, but of course can be noticed only by comparing enough persons.
    Monday, January 27, 2020 12:44 PM
  • Why? Have you profiled the code and identified that out of all your code this particular type is causing all your performance issues. If the answer is no then please realize you are trading off type safety and ease of use over an optimization that probably isn't going to save you anything.

    The reality is that the perf will depend on what kind of type Person is. If it is a value type then your generic version will take up more memory at runtime but will perform better because no boxing is involved. But the cost of boxing isn't noticeable unless you're doing it a lot. If the type is a reference type then performance will be the same other than your object implementation doing an extra cast which has nothing to do with IComparer<T> vs IComparer but your implementation.

    In almost all cases you'll actually implement both because there is still some code that only works with IComparer while most code works with IComparer<T>. So you implement both and code that is generic aware uses the newer implementation and the code that isn't uses the older one. It isn't up to you to decide which one they'll use anyway.

    class SortYearAscending : IComparer<Person>, IComparer
        {
            //Used by code that supports IComparer<T>
            public int Compare(Person P1,Person P2)
            {
                if (P1.Year > P1.Year)
                    return 1;
                else if (P1.Year < P1.Year)
                    return -1;
                else return 0; 
            }
    
            //Used by code that doesn't support IComparer<T>
            int IComparer.Compare ( object x, object y ) => Compare((Person)x, (Person)y);
        }


    Michael Taylor http://www.michaeltaylorp3.net

    Monday, January 27, 2020 2:45 PM
    Moderator