[질문] shared library 와 static library의 memory 사용량 차이??
글쓴이: twins99 / 작성시간: 화, 2008/07/01 - 10:22오전
궁금한게 있습니다.
shared library(.so)와 static(.a)로 만든 동일한 library를 사용 할 경우
memory 사용량에서는 어떤 차이가 있나요?
일단 실행 binary의 크기가 다르니 초기 실행시는 static 으로 compile된 놈을 사용할때가 사용 memory량이 클것으로 생각되는데,
이후 library를 사용하는 code가 실행되면 .so를 사용하는 경우라도 library를 memory로 올릴테니 static library
를 사용할 때와 차이가 없지 않을까 싶어서요.
shared library를 사용할 경우 어떤 이점이 있을까요.
그리고 shared library가 memory에 올라온 시점과 memory에서 내려가는 상황도 궁금합니다.
궁금합니다.
Forums:
shared library는
shared library는 라이브러리를 여러 프로그램이 사용될때 라이브러리 코드 영역을 공유하게 됩니다.
보통 코드 영역은 변경하지 않죠.
Written By the Black Knight of Destruction
Written By the Black Knight of Destruction
어차피 요즘 OS는
어차피 요즘 OS는 프로그램이 실행될 때 바이너리 이미지를 통째로 메모리에 올리지 않습니다. 필요할 때마다 그 부분을 읽어서 올리죠.
그러므로 statically linked library를 사용한다고 해도 프로그램이 시작하는 순간에 메모리를 그만큼 더 잡아먹지는 않을 겁니다.
윗분 말씀대로 shared
윗분 말씀대로 shared library는 하나만 로딩해서 여러 프로세스가 공유해서 사용합니다.
프로세스마다 따로 로딩하지 않죠.
때문에 말씀하시는것과 같은 메모리 낭비는 없음.
Re:
정적 라이브러리의 경우 장점은 공유 라이브러리에 비해 실행 속도가 빠르고 배포에 제약이 없습니다. 단점은 해당 라이브러리를 필요로하는 모든 경우 같은 정적 라이브러리가 링크되기때문에 배포 파일들의 사이즈가 커진다는 겁니다. 그러므로 하드 디스크 공간도 더 차지하고 메모리도 더 많이 차지하겠지요. 유닉스 시스템의 경우 그때그때 필요한 부분만 메모리에 로딩하는 demand paging을 사용하기때문에 정적인 라이브러리의 메모리 사용률과 공유 라이브러리의 그것의 차이가 크지 않다고 합니다.
참고로 share library와 dynamic link library는 다른 개념입니다. 그러나 대부분의 경우 dynamic link library는 share library를 만들 때 사용된다고 합디다.
공유 라이브러리는 하나의 라이브러리를 그 라이브러리를 사용하는 서로 다른 여러 개의 프로그램이 공유함으로써 각각의 프로그램의 사이즈가 작아진다는 장점이 있습니다. 단점은 실행 속도가 느리고 실행 파일이 배포된 시스템에 컴파일시 사용된 메이저 버전의 동적 라이브러리가 없거나 혹은 있어도 메이져 버전이 다르면 프로그램이 작동되지 않습니다. (그래서 이런 경우 만약을 대비해서 공유 라이브러리도 함께 배포한다고 합니다.)
마지막으로 공유 라이브러리는 해당 공유 라이브러리를 필요로 하는 프로세스가 하나라도 있으면 메모리에 로딩되어서 해당 라이브러리를 필요로하는 프로세스가 하나도 없을 때까지 계속 메모리에 남아 있습니다.
shared library 와 dynamic link library?
저는 비슷한 기술에 대하여 linux 에서는 shared library, windows 에서는 dynamic link library 라 부르는 걸로 알고 있었는데, 구체적으로 어떤 점에서 개념적으로 다른지 궁금합니다.
프로그래밍 하다 차이점을 느끼는 점으로는, linux 의 shared library 의 경우 shared library 화일(.so) 만으로도 링킹이 가능하지만, windows 의 dynamic link library 의 경우 dll + stub library (implicit linking시) 가 있어야 링킹이 가능하다 정도여서요. 혹은 실질적으로 개발을 할 때 gcc 의 경우 모든 심볼에 대해 기본적으로 export 설정이 가능하지만 vc++ 의 경우 def 화일을 생성하거나 export 될 함수 선언부에 별도 매크로를 추가해주어야 한다는 점 정도.. 실제 동작 매커니즘의 차이는 아직 잘 몰라서요.
그리고 공유 라이브러리의 실행 속도가 느리다 하셨는데, 어떤 이유에서인지 궁금합니다. 개인적으로는 첫 라이브러리 로딩 시간 외에는, 그 이후는 함수 포인터에 의한 호출인지라, 혹 정적 라이브러리 빌드시 전역 최적화를 통한 함수 호출 최적화를 타지 못한다는 점 정도말고는 딱히 떠오르는게 없어서요. (Windows 같은 경우 아에 WinAPI 들이 DLL 기반이고..)
개념의 차이가 아닐까요?
말 그대로 메모리에 로딩된 하나 라이브러리를 여러 실행 프로그램에서 공유하는 것과
특정 라이브러리를 컴파일 시가 아닌 실행시에 로딩해서 사용한다는 개념적인 부분을
이야기 하시는 것 같습니다.
공유 라이브러리가 동적으로 로딩되야 된다거나 동적으로 로딩된 라이브러리가
꼭 공유되야 한다는 내용은 아니라고 말씀하신 것 같네요.
아 kldp 들어오면 궁금한 점을 해결하는 것보다 공부할게 더 늘어나네요..
-------------
포탈이는 불사신
-------------
포탈이는 불사신
제가 알기로는...
동적 링크는 더 느리긴 하지만 문제 될 정도로 느린 일은 없다고 생각됩니다. (막연히 느리다고 하시기에...)
일단 제 생각을 단다면.. 사용량 차이는 분명 있는것은 맞습니다.
단일 프로그램에서 사용하는 라이브러리로 보면 정적이나 동적이나 차이가 별로 없을테지만...
윈도우즈에서 GUI로 돌아가는 수많은 프로그램들이 사용하는 GDI또는 GDI+객체들이 전부 정적 링크가 되어 있으면 메모리 사용량은 얼마나 늘어날까요?
아.. 리눅스에서의 기준이라면 glib라든지 X의 라이브러리가 전부 정적이였다면... 상황은 어떨지 대강 예상되나요?
프로그램 하나하나가 부르는 수많은 함수들이 전부 정적이였다면 커널은 어떤게 공통 코드인지 알 수 없어 죄다 메모리에 올려서 실행이 될것입니다.
하지만 동적은 아닙니다. 이것이 중복 되는구나. 라고 인식을 할 수 있으며 중복이 되는건 다시 부르는게 아니라 해당 함수의 가상 주소를 넘겨 줄 뿐입니다.
(만약 정적이라고 해도 한번 부른건 메모리에서 해제하면 자원 낭비가 덜하지 않느냐... 라고 혹여나 물어 보신다면.. 그 영역 해제, 활당이 그때그때 불러지면 동적인 라이브러리에서 가상 주소를 넘겨 주는것보다 효율적일까요?)
마지막 질문 하신 내용은 저도 절차를 잘 모르므로 생략하겠습니다.
댓글 달기