Yes, tweaking it would be the only uncertainty.
One has to pre-suppose the full data is sent when one enters, and is not dynamically updated while in the history. Therefore, it's not out of the question they could spawn a low priority thread to continuously order the data while one enters, but de-couple it from viewing thread so it would not wait on it to be complete. The sorting thread could asynchronously update the process displaying the data as it finishes pages. This would allow fast initial access to history, and essentially eliminate page delay. Since the bottleneck on virtually all computers now is single-threaded performance, as most have several cores, the background thread would not materially impact foreground performance. But, that's not 100%, and would have to be tested. If it did, only a few pages at a time. If not, in most cases, then it could work until all the pages are correctly created, then quit.
There are a couple of other changes that might help. I'm of the opinion the "Visit Tavern" stuff is just background noise for most people. I also think the parsing solutions are poorly implemented. For example, I can get all events, or any one of the others. Those are limited. I would recommend using check boxes next to each, so the selection could include any combination of events. I'd also suggest that the annoying selection box, which lowers the number of viewable events, disappears after use, but remembers the settings. If changes are needed, it can be brought back up as it was initially, and changes can be made there. This gives one the option of modifying what is viewable, without losing 10% of their viewing window.
This would address issues like Visit Tavern, which I think most people would remove, since it's of limited use, and takes up a lot of space.
