This one is rather complicated and probably needs more research. Therefore everythign concerning this issue goes here. I'd appreciate if nobody posts about their problems with it in here so it can be used by the devs and/or other tech savy people.

When iterating the QuestLog, it will lock up the game for for short periods of time, usually 15-30ms (on my machine anyway). One such lock will occasionally happen in Questie:AstroGetAllCurrentQuestHashesAsMeta when receiving the QuestHash. However logging times within Questie:getQuestHash always shows times of 0ms.

Therefore, I assume that it is the game locking up due to more than 1 addon iterating the QuestLog or something similar. One possible solution I can see is moving away from SelectQuestLogEntry(i) and instead using the questID parameter in GetNumQuestLeaderBoards(questID)and GetQuestLogLeaderBoard(i, questID). I'm hoping this would solve things because the current QuestLog state isn't being changed at all anymore.
However, that would cause issues with GetQuestLogQuestText() which NEEDS for an entry to be selected. So there would need to be some sort of caching implemented in that function, as we already hook it anyway.

We can also try replacing SelectQuestLogEntry(id)with QuestLog_SetSelection(id) and see if anything improves. Again, this is just a guess.

We do definitely need to find the culprit though. I thik we can get this down to 0ms just like the rest easily. The lockups are really annoying and need to be dealt with though.

again I REALLY want us to switch to an iterative ticking system for the questlog parser. Have it check ONE questlog id per OnUpdate, and have QUEST_LOG_UPDATED event just set needsUpdate++;

AstroGetAllCurrentQuestHashesAsMeta should be returning cached information

Rewrite every function to use a cached version then.

Caching hashes fixed this