I was reading through some earlier threads around performance of the users.txt file with high counts of players in groups other than "users" (I too use autopromote in my sandbox server in conjunction with URS to limit access to sweps and ents to specific ranks earned based on time on the server). While I don't believe I have lag problems around accessing users.txt, I do feel a bit of lag whenever someone spawns in (which I believe is related more to Patch Protect and its reshuffling of touch rights as people spawn in).
The keyword is "believe". I have no hard data - just subjective experience. Enter potentially ridiculous idea #324 into my wee little brain. If I wanted to try and track true diagnostic timing information around GMod hooks and the processes running within them, would something like this make sense...?
1) Create a high priority hook (-20) for all GMod hooks I'm interested in tracking (ie, PlayerInitialSpawn). The only logic within each is to record the current high precision time.
2) Create a low priority hook (20) for the same GMod hooks, the logic of which calculates a differential between the current precision time and the previous start time for that particular hook.
3) The delta here should represent the total processing time across all of the various active hooks... roughly, anyway.
In theory this should start to give me insight into high-intensive processing areas, and I can begin to narrow my investigation/refactoring to the implementations of the hook(s) that show the highest consumption.
Make sense, or am I missing something that might skew the results? I realize I'm not going to get actual cpu time from any of this -- but I think it'll give me relative processing requirements and might cast a bright light on hooks that are causing noticeable lag.
Thanks.