파이썬 2.3의 공유 라이브러리 지원

by

이미 해본 분들은 아시다시피 ~.~, 파이썬 2.3에서는 –enable-shared를 주면 공유 라이브러리로 사용이 가능하도록 돼서, libpython2.3.so가 1메가짜리가 나오고 python은 3천 바이트짜리가 나옵니다.

그래서, 이야 멋지다 하고 메모리 절약에 도움이 되지 않을까 하는 생각에, FreeBSD포트 [FreshPorts]lang/python 에는 덥썩 shared를 디폴트로 해 버렸는데, 다행히도 python-dev 메일링에 누가 “왜 –enable-shared가 디폴트가 아닌가요”하는 질문에 Martin v. Löwis가 좋은 대답을 해 주어서, 덕분에 잘못 알고 있었던 것을 바로 잡게 되었습니다. 으흐흐 (다들 알던 것인가;;)

웬지 공유 안 할 것 같아 보였던, static 바이너리도 inode가 같은 경우에는, text 이미지를 메모리에서 모두 공유한다는군요 (두둥!) ~.~;;

Löwis의 가르침(!)을 요약하면..

  • 파이썬 바이너리가 1개만 있으면, 걔네들은 모두 공유라이브러리 만큼 전부 메모리나 디스크 공간을 공유한다. 그런데, 거의 대부분의 파이썬 애플리케이션들이 파이썬 바이너리를 따로 쓰는 게 아니기 때문에, 대부분의 파이썬 애플리케이션들은 실행 파일 이미지를 메모리에서 공유한다고 볼 수 있다. 특별한 예외라면 [WWW]mod_python이 있는데, mod_python은 아파치 바이너리를 통해서 공유돼서, 다른 파이썬 바이너리와는 공유하지 않지만, 아파치 바이너리들 끼리 공유해서 같은 효과를 얻는다.

  • 공유 라이브러리를 유지하는 것은 상당한 관리상 문제점이 따른다. 어떤 경우에는 인스톨이 제대로 안 될 수도 있고, 공유라이브러리 링커에 따라 못 찾게 될 수도 있다.

  • 공유 라이브러리를 사용하면, 시작하는 시간이 길어진다. 또한, [WWW]ld.so에 디렉토리가 몇 개 더 추가되어야 하고, 빌트인 모듈로 컴파일되지 않은 파이썬 모듈까지 모두 공유라이브러리 패스에 들어가야 한다. (퍼키 주: 이 부분은 적어도 FreeBSD에서는 사실이 아닙니다. FreeBSD에서는 그냥 [WWW]dlopen(3)으로 절대경로찾도록 되기 때문에, 정적 컴파일한 것이나 같습니다.)

  • 공유 라이브러리를 사용하면, 실행 시 효율성이 떨어진다. PIC (Position-Independent-Code)는 일반적으로 non-PIC 바이너리보다 최적화에서 불리하다. ([WWW]블루님 주: 현실적으로는 거의 차이가 없다고 합니다. 😉

  • 공유 라이브러리를 들고 있으면, 관리 비용이 더 많이 든다. 컴파일러, 링커, 다이내믹 링커 등등 거의 모든 개발 툴에서 기존에 없었던 문제가 발생될 수 있고, 이에 대해서 일일이 고려해야한다.

    • 흐흐흐. 그래서, FreeBSD의 [FreshPorts]lang/python 포트도 별도의 공유 라이브러리 포트를 분리해 내고, 정적 컴파일로 다시 돌리려고 합니다. 만세 \(-.-)/

    (Martin v. Löwis의 원문은 [WWW]http://mail.python.org/pipermail/python-dev/2003-August/037472.html)

    7 thoughts on “파이썬 2.3의 공유 라이브러리 지원”

    Comments are closed.