I can't confirm your observation, i.e. my 64-bit HiRes.so (for example) is just 35k.

Maybe you've somehow managed to statically link in libc (which is roughly 2 MB)?  What does ldd say?  Mine says:

$ ldd /usr/local/lib/perl5/5.12.2/x86_64-linux-thread-multi/auto/Time/
+HiRes/HiRes.so
    linux-vdso.so.1 =>  (0x00007fff399fe000)
    librt.so.1 => /lib/librt.so.1 (0x00007f2e314fe000)
    libc.so.6 => /lib/libc.so.6 (0x00007f2e3119c000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00007f2e30f7f000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2e31911000)
[download]

(the entry libc.so.6 => ... would be missing if linked statically)

I'm seeing libc.so.6:

% ldd ./auto/Time/HiRes/HiRes.so
    librt.so.1 => /lib64/librt.so.1 (0x00002af3572c2000)
    libc.so.6 => /lib64/libc.so.6 (0x00002af3574cb000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00002af357822000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003bf0000000)
[download]

What do you get when you run this script?

use Time::HiRes;

open(SMAPS, "/proc/$$/smaps");
while (<SMAPS>) {
  if (m/^\d/) {
    chomp($lib = (split(' ', $_))[5]);
  } elsif (m/^Size:\s*(\d+.*)/) {
    my $size = $1;
    print "$size $lib\n" if ($lib =~ m/HiRes/);
  }
}
[download]

I am getting (Centos 5.5, perl 5.8):

24 kB /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes
+/HiRes.so
2044 kB /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiR
+es/HiRes.so
4 kB /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/auto/Time/HiRes/
+HiRes.so
[download]

Does the 2044 kB entry represent real memory usage (unshared with any other library)? I'm trying to determine how much real memory my application is using.

Ah, sorry, I missed that you were talking about memory usage (as opposed to shared object file size).  And yes, I do get similar numbers.

Note that the "Size" figures (like your 2044 kB) are rather meaningless. You can think of them as the address regions that a process could (in theory) access without causing a segfault.  As long as it doesn't, the figure is irrelevant for what one typically thinks of as "memory usage". What's more interesting in this regard is the resident size (RSS), in particular the private (non-shared) pages of it. But note that this is also a somewhat too simplified view of things...

Anyhow, for a more detailed analysis of memory usage, you might be interested in exmap. Its docs give a good overview of the terminolgy, btw.

Also, there's Linux::Smaps, so you don't have to parse the proc file yourself. And IIRC, there's even a script "out there" (using this module) which assembles the smaps info and creates an easier-to-digest summary report.  Unfortunately, I can't remember its name, but maybe you can dig it up...

For what (little) it may be worth, I have noticed ... especially in the 64-bit worlds ... that memory region sizes, as reported by tools like these, can be a lot bigger until some amount of actual memory pressure is exerted that, so to speak, “compels the system to clean house a little bit.”   It seems to go straight for big allocations.   (And, this strategy seems to work just fine.)   I haven’t delved into the guts of Linux to know what might be influencing the designers’ decisions in the case of 64-bit, nor do I intend to, but the algorithms are obviously different.   (Maybe it’s partly affected by the simple fact that “chips are cheap” now?)   Of course, operating systems are always (well-) designed to be lazy, because the tradeoff is always “space vs. time.”