Why kinfo_getvmmap is sometimes so expensive?

[Yuri]

The function getProcessSizeBytes, calculating the total size of the 
process, runs once per second. I have two processes of the same kind, 
but with the different run history.

Process #1 didn't do much work, its total size is 1.5 GB, google 
perftools library says that it currently has 1.2GB allocated.

Process #2 did a lot of work, its total size is 6.9 GB, but most of the 
used memory was freed, and google perftools library also says that it 
currently has only 1.2GB allocated.

Both processes have about 140 lines in /proc/<pid>/map.


What bothers me is that getProcessSizeBytes run once per second makes 
process #1 to consume ~0.5% CPU, and process #2 to consume ~14% CPU. 
When I stop running getProcessSizeBytes, CPU times of both processes go 
to zero.


Obviously, google perftools doesn't unmap the memory, and the totals of 
block sizes in /proc/<pid>/map is much higher for process #2 with about 
the same block count. But why does this cause 14% of CPU consumption? 
And why another, similar process that goes through about the same number 
of blocks only has 0.5% CPU consumption?


uint64_t getProcessSizeBytes() {
   int i, cnt = 0;
   struct kinfo_vmentry *kvm0, *kvm;
   m_uint64_t memSz = 0;

   kvm0 = ::kinfo_getvmmap(::getpid(), &cnt);

   for (i = 0, kvm = kvm0; i<cnt; i++, kvm++)
     memSz += (kvm->kve_end-kvm->kve_start);

   free(kvm0);
   return (memSz);
}


FreeBSD 10.3


Yuri