Find the answer to your Linux question:
Results 1 to 6 of 6
Hi, I found a very strange thing when I linked my executable with a shared library. That is the executable only references a small function of the shared library, and ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    May 2010
    Posts
    4

    Probable overhead of using a shared library


    Hi,
    I found a very strange thing when I linked my executable with a shared library. That is the executable only references a small function of the shared library, and the size of this function is only hundred bytes, but when I check the /proc/pid/smaps, I found that the 'Rss' of this shared library is 76 KB that is much larger than the actual size of the referenced function. I just wonder why it is. What's the extra data in this 76 KB of memory? Thanks in advance.
    Code:
    00c4e000-00d73000 r-xp 00000000 00:15 38896026   /home/xhbf63/Desktop/libnewshared.so
    Size:               1172 kB
    Rss:                  76 kB
    Pss:                  76 kB
    Shared_Clean:          0 kB
    Shared_Dirty:          0 kB
    Private_Clean:        76 kB
    Private_Dirty:         0 kB
    Referenced:           76 kB
    Swap:                  0 kB
    KernelPageSize:        4 kB
    MMUPageSize:           4 kB

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,737
    Unlike a static library, linking to a function in a shared library pulls in the entire library. You will save resources if more than one application uses the library.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    May 2010
    Posts
    4
    Does it mean if there is only one application calls the functions of a shared library, it is better to change this shared library to a static library? Do you have any idea of which sections of a shared library should be loaded in the physical memory before any function is called? Thanks.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,737
    Thinking of the Windoze term for it, a dynamic link library, helps conceptualize what is going on. When the shared library is loaded into memory (yes, it uses physical memory), the parts (translation units == *.o) that are needed are linked into the running application. IE, all the global data values and used functions will force the implementing translation units into the application's memory. However, the code (text segment) parts will only be in computer memory once, though the data parts (writable global variables) will have a copy in each application that uses them. So, each linking application will show that it is using the library memory memory (text + data), but only one copy of the actual memory will be in the computer memory, hence the term "shared library". If you look at the output of a tool like 'top' you will see columns like "virt" (virtual memory), "res" (or "rss" - resident set size), and "shr" (shared memory). The resident set size is the actual memory the application is using, and shared memoroy is what is in its memory, but possibly shared with other applications. The virtual memory column is what the application thinks it is using, which is resident, shared library, and shared system (mapped) memory.

    So, what all this means, is that it is possible, but difficult, to know exactly how much of the system memory a user application is really using. In any case, your /proc/pid/smaps output is pretty good at showing what is really what: Rss = resident set size, Private_Clean + Private_Dirty = the amount of memory your application is really using by itself. I'm not sure off-hand what the "Pss" field is referring to, though it is pretty obvious that it maps directly to "Rss" in this case.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  6. #5
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,737
    So, to come back to your original question as to which is better to use, a static library, direct file.o, or shared library, the answer has to be "it depends". If only your application will be using that code, then linking it directly either via a static library (libname.a), or translation unit (filename.o) makes since. If, however, either your code or the translation unit code makes use of functions or variables in another translation unit, then either linking with a static or shared library is appropriate.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  7. #6
    Linux Newbie unlimitedscolobb's Avatar
    Join Date
    Jan 2008
    Posts
    120
    I wonder how much sense it makes to create a library which will be used by only one application. One could as well implement the corresponding functionality within the program itself, but I may be overlooking something.

    If one is using a third-party library, however, I think a shared (dynamically loaded) library would a little bit better, because one will be able to update to new minor versions of the library on the fly, without the need to recompile things.

    Nevertheless, I will completely agree with Rubberman's "It depends". If you are running on an embedded platform with scarce memory, recompiling instead of using additional memory would certainly be more welcome.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •