search

epics-extensions / ca-gateway

Channel Access PV Gateway
http://www.aps.anl.gov/epics/extensions/gateway/
Other
17 stars 17 forks source link

Make sure a large gp hash table is used #38

Open ralphlange opened 2 years ago

ralphlange commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.