Make sure a large gp hash table is used

[ralphlange]

Reported by Lana Abadie (ITER):

Investigating long reconnect times through a CA Gateway, profiling found that the Gateway spends a lot of time inside GPHENTRY * epicsStdCall gphFindParse(gphPvt *pgphPvt, const char *name, size_t len, void *pvtid), namely doing string comparisons.

In that general purpose hash table, linear search and string comparisons are done in the case of collisions, i.e., when hash buckets are found not empty.

The CA Gateway – being an application that may serve many PVs and always runs on a virtual memory system – should use a large gp hash table.

[anjohnson]

Interesting, what is the hash table size it uses? Jeff Hill provided and uses his own C++ hash table implementation in resourceLib.h which adjusts the hash table size dynamically, maybe it would be worth looking at switching to that instead?

[mdavidsaver]

imo. any re-working should favor std::map as the more sustainable, and perhaps better performing, alternative. Maybe with ifdefs to use std::unordered_map when available.