Execution speed of IComparer interface...

[ALX]

It seems that the amount of code that I need to write to use the IComparer interface to sort an array of similar structures is substantially larger and more complicated than if I just do the sorting manually in code. My current sorting method sets up a temporary array and copies the original array to the temporary array by the lowest element first. So the code needs to traverse the entire original array once for each element copied.
My question...
Is the execution speed much faster using the "Array.Sort(...)" interface, to make it worth the effort ? My thinking is that it would not be all that much faster since the NET has to call my subroutines to do the sorting anyway.

 

[jmcilhinney]

This is OOP and one of the aims is code reuse. With an IComparer you write the code in a class and forget it. Whenever you want to sort an array you simply create an instance of your IComparer and pass it to Array.Sort in one line of code. Also, you have to compare the aray elements to sort them whether you write your own sorting method or write an IComparer. How are you comparing them if you're writing your own routine? What sorting algorithm are you using? Is it as efficient as that used by Array.Sort? I don't know but I would imagine that Array.Sort uses the QuickSort algorithm, so if you're using one that is less efficient then you would be slowing things down. The best way to test execution speed is to execute. Just use the two methods to sort the same array 1000 times or something like that and time them.