Lazy Developer

지난 번 Comb Sort를 소개했던 포스팅에서 말씀 드렸듯이, Bubble Sort, Comb Sort, 그리고 닷넷의 기본 소팅 알고리즘인 Quick Sort의 성능을 비교해보았습니다.

테스트 소스는 지난 번 소스에 Quick Sort를 호출하는 부분을 추가한 것 뿐입니다. 그리고 Quick Sort도 따로 구현한 것이 아니라 닷넷의 System.Array.Sort()를 호출하는 방식으로 했습니다.

배열의 개수를 파라미터로 넘길 수 있도록 코딩 했습니다. 그래서 테스트는 10개, 100개, 1000개 이렇게 10배씩 늘려나가는 방식으로 진행했고, 3번 해서 그 평균을 구했습니다. 결과는 이렇습니다. (단위는 millisecond 즉, 100분의 1초입니다)

확실히 Bubble Sort는 매우 매우 느립니다. ^^;; 그리고 Comb Sort는 100개 이하에서는 오히려 Quick Sort보다도 빠른데, 1000개 정도부터는 Quick Sort의 상대가 되질 않네요.

그래서 따로 Comb Sort 와 Quick Sort 만을 따로 비교를 해보았습니다. 이 두 가지 Sorting은 100000개와 1000000개도 테스트할 수 있었습니다. (Bubble Sort로는 도저히 이 숫자는 할 수가 없더군요)

그래도 빠르다고 생각했던 Comb Sort도 100000개 이상부터는 Quick Sort와 비교가 불가능한 성능을 보여줍니다. 정말 Quick Sort가 짱 이네요 ^^

Quick Sort에 대해서 자세히 알고 싶은 분들은 Wikipedia의 Quick Sort 항목을 참조하시길 바랍니다. 오른 편에 있는 그림이 정말 Quick Sort의 모든 것을 보여주네요.

그리고 Reflector로 당연히 닷넷의 소스도 확인할 수가 있습니다. 아래 그림과 소스처럼 말이죠. ^^

* 아래 덧글에서 보실 수 있듯이, exedra님 지적 때문에 일부 소스와 비교 데이터가 수정되었습니다. (2008-01-14)

회사 솔루션 코드 중에 VB로 된 Comb Sort 코드가 있길래, C#으로 재 작성해보았습니다.

그러면서 가장 기본적인 Bubble Sort와 성능 차이가 얼마나 되나 비교도 해 봤습니다.

Comb Sort의 내용에 대해서는 Wikipedia의 Comb_sort 항목을 참조하시면 됩니다.

코드는 아래와 같습니다.

1000건을 Sorting했을 때 결과는 이렇습니다.

차이가 매우 크다는 것을 보실 수 있습니다. Comb Sort가 꽤 빠른 Sorting 알고리즘이라는 것을 알 수가 있습니다. 다음 번에 기회가 나면, .NET의 기본 Sort 알고리즘인 Quick Sort와 한 번 비교해보도록 하겠습니다.

메서드를 작성할 때에, Argument가 다 정상적으로 들어올거라고 가정해서는 절대로 안 된다. 반드시 다음과 같이 Validation 코드를 작성해서, 메서드의 가장 위에 둘 필요가 있다.

1. Argument 가 null인지 검사해서, null이라면 NullArgumentException을 던져야 한다. 아래 코드는 .NET Framework의 System.Windows.Annotations.Annotation 클래스의 WriteXml메서드의 가장 윗부분 코드이다.

2. 각 argument값 자체의 이상 유무를 검사한다.
기본적인 string 이라면, 전에 올렸던 글처럼 IsNullOrEmpty 메서드를 써서 검사하고, 다른 type이라면.. -_-;; 다양한 것을 다 여기서 다루기는 힘드므로.. 일단 적절하게 검사한다.  아래 예제는 위에서도 사용한 System.Windows.Annotations.Annotation 클래스의 WriteXml메서드의 일부분인데, 넘어온 XML의 내부 스트링들을 IsNullOrEmpty메서드로 검사해서, 없을 경우 채워넣는 코드이다.

AES는 미국 정부에서 민감한 정보들을 암호화하는 데 사용되는 표준 암/복호화 알고리즘이다. 현재 업계 표준이고, 아직까지는 알려진 약점이 없는 가장 안전한 암/복호화 알고리즘이다. 최근에 일부 SI 프로젝트에서는 이 방식을 꼭 쓸 것을 요구하기도 한다.

1. 암호화

C#에서는 try-catch-finally 구조를 사용해서 각 예외처리를 수행한다. 그런데 이 구조에서 예전에 제가 C#을 처음 익힐 때부터 약간 혼란스러웠던 것이 있다.

바로 Return 문이 어디에 위치해야 하는가이다...

MSDN 라이브러리의 try-catch-finally 구조에 대한 설명을 보자.

A common usage of catch and finally together is to obtain and use resources in a try block, deal with exceptional circumstances in a catch block, and release the resources in the finally block.

Catch와 finally를 같이 쓸 때의 일반적인 사용법은 try 블록에서 리소스를 얻어내서 사용하고, catch 블록에서는 예외적인 상황을 다루며, finally 블록에서그 리소스를 해제한다.

즉, return을 어디 두어야 하는 지는 어디에도 없다.

샘플도 교묘하게 void를 리턴 하는 함수를 만들어서 피해가고 있다.

그래서 두 가지 방법으로 코드를 작성해 보았다.

//return문이 가장 마지막에 위치

public int ReturnInLastLine()

{

int i = 0;

PrivateOBJ obj = null;

try

{

obj = new PrivateOBJ();

i = obj.GetINT();

}

catch(Exception ex)

{

throw ex;

}

finally

{

obj = null;

}

return i;

}

//try블록 내부에 return이 위치

public int ReturnInTry()

{

int i = 0;

PrivateOBJ obj = null;

try

{

obj = new PrivateOBJ();

i = obj.GetINT();

           return i;

}

catch(Exception ex)

{

throw ex;

}

finally

{

obj = null;

}

}

그리고, 이클래스를 컴파일한다음  .NET Reflector로 디스어셈블한 코드를 보았다.

결과는놀랍게도,

public int ReturnInLastLine()
{
int num1 = 0;
PrivateOBJ eobj1 = null;
try
{
eobj1 = new PrivateOBJ();
num1 = eobj1.GetINT();
}
catch (Exception exception1)
{
throw exception1;
}
finally
{
eobj1 = null;
}
return num1;
}

public int ReturnInTry()
{
int num2;
int num1 = 0;
PrivateOBJ eobj1 = null;
try
{
eobj1 = new PrivateOBJ();
num1 = eobj1.GetINT();

//여기 주의

//원 소스 코드에는 여기에 return이 있다. 그런데?
num2 = num1;
}
catch (Exception exception1)
{
throw exception1;
}
finally
{
eobj1 = null;
}

//여기에 리턴문이 있다.
return num2;
}

IL 코드도 이와 거의 유사하다고 보면 된다.

즉, return을 어느 위치에 두던지 간에 실제로 IL로 컴파일된 코드에서는 return이 가장 마지막에 위치한다는 것이다.

그래서 두 번째 try 내부에 리턴이 있는 경우를 보면 IL 코드는 내부적으로 (코드에는 없는) 변수를 하나
더 선언해서 거기에 값을 할당하고 그 변수를 최종적으로 리턴을 수행할 때 사용하는 것을 볼 수가 있다.

결론

1. 코드 상에서 return문이 어디에 있더라도, IL 코드 상에서는 가장 마지막 라인에 return문이 있게 된다. 결론적으로 마지막에 두는 것이 맞다는 것이다.

2. 코드에 Try 블록 혹은 catch 블록 혹은 여러 군데에 return을 위치시킬 수 있다. 심지어 if-else 문을 사용해서 각각 return하는 경우도 있다. (절대로 권장하지 않는 코딩방법!!) 그 경우 IL이 내부적으로 최종 리턴을 위해서 변수를 하나씩 더 할당한다. 이 값이 만약 매우 큰 데이터셋이라면? 메모리 누수의 원인이 될 수도 있을 듯 하다. 결과적으로 비효율적인 코드라는 것이고, 피해야 할 코딩이 되는 것이다.