LLM 작성글이라 내용 중 틀린 내용이 있기는 한데 귀찮아서 고치지 않았습니다. ㅎㅎ

아마 타 언어 컴파일러도 이럴 것 같습니다.

Ada의 case when 최적화와 errno → 예외 매핑

시스템 프로그래밍을 하다 보면 errno를 받아서 Ada 예외로 변환하는 작업이 필요합니다. Clair 프로젝트에서도 Clair.Error 패키지에 수십 개의 예외와 errno 상수가 정의되어 있죠. 문제는 이걸 변환하는 함수(Raise_From_Errno)를 작성할 때 case when 절이 100~150개쯤 생긴다는 겁니다.

그럼 성능은 어떨까요? 단순 배열 탐색과 비교해보겠습니다.

1. case when 150개일 때

Ada 컴파일러(GNAT 등)는 case 문을 최적화합니다.

• 값이 연속적(dense) → jump table 생성 → 사실상 정적 배열 인덱싱과 동일한 O(1) 성능
  
• 값이 드문드문(sparse) → 비교 체인이나 이진 탐색 트리 생성 → O(log N) 또는 O(N)
  

errno 값은 1부터 97까지 연속적이므로, Ada 컴파일러는 jump table을 만들어줍니다. 즉, case when 150개라도 성능은 배열 인덱싱과 같은 수준입니다.

2. 정적 배열 + 2진 탐색

직접 (errno, exception) 쌍을 배열에 넣고 이진 탐색을 하면 O(log N)입니다.
N=150이면 log₂(150) ≈ 7번 비교. 성능상 큰 문제는 없지만, case when jump table보다는 느립니다.
장점은 유지보수성: 새 errno 추가 시 배열에만 넣으면 됩니다.

3. Raise_From_Errno 구현 방법

Raise_From_Errno 프로시저는 두 가지 방식으로 구현할 수 있습니다:

1. 배열 인덱스 방식

   • 에러 코드가 연속적일 경우, 배열 인덱스처럼 직접 접근 가능.
     
   • Ada 컴파일러가 case when을 jump table로 최적화하므로 사실상 O(1).
     

2. 정적 배열 + 이진 탐색 방식

   • 에러 코드가 연속적이지 않거나, 예외 매핑이 드문드문일 경우.
     
   • (errno, exception) 쌍을 정렬된 배열에 넣고 이진 탐색으로 찾음.
     
   • O(log N) 성능, 유지보수성은 뛰어남.
     

4. 결론

• 성능 최적화가 최우선이면 → case when (jump table, O(1))
  
• 유지보수성과 자동화가 중요하면 → 정적 배열 + 이진 탐색 (O(log N), 충분히 빠름)
  
• Clair 같은 시스템 프로그래밍 라이브러리에서는 자동 생성된 case when이 가장 Ada스럽고, 성능도 최적입니다.
  

👉 요약: Ada의 case when은 내부적으로 정적 배열 매핑(jump table)로 최적화되므로, errno 매핑에 가장 적합합니다. 다만 연속적이지 않은 경우에는 정적 배열 + 이진 탐색도 좋은 대안이 될 수 있습니다.