Re: Role of profile/hashtable.h?!?

[Silvius Rus <rus at google dot com>]

On Sun, Jan 3, 2010 at 8:33 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
>
> Hi,
>
> I was going through the debug / profile subdirs and noticed
> profile/hashtable.h, which appears to be copied over with minimal
> changes from the legacy HP/SGI hashed containers implementation. I don't
> see however the legacy hashed containers themselves in profile/, which
> is good by the way, and I don't understand which is the role of
> hashtable.h itself here... Can you clarify?
>
> Thanks,
> Paolo.

If I remember well, we had to clone part of hashtable.h in order to
instrument decisions such as when to rehash.  These decisions are
based on private data such as _M_num_elements.  Other private data
member values may be collected by instrumentation code.  In the case
of hashtable-based containers, profile instrumentation only cares
about hashtable details (distribution, rehashing), so instead of
instrumenting hash_map and hash_set, we decided to instrument only
hashtable.  Thus you only see hashtable.h and not hash_map or
hash_set.  Is there a better way to do this, which ideally would
eliminate or reduce greatly the amount of cloning?

I will be revisiting the include/profile/ code early this coming week
and port a few needed fixes from the profile-stdlib branch and local
patches.  In case you notice anything else questionable within
include/profile, this is a very good time to bring it up.

Thank you,
Silvius