search

scragg0x / realms-wiki

Git based wiki inspired by Gollum
http://realms.io
GNU General Public License v2.0
831 stars 90 forks source link

History view performance improvements #149

Closed gazpachoking closed 8 years ago

gazpachoking commented 8 years ago

Getting the history for a page can be very slow for repos with a large number of commits. I think there is some room for improvement. Started thinking about this when doing #147. Wanted to separate discussion from that PR though. Here are some of my ideas, looking for any feedback:

  1. When generating history, (at least the first time, depending on what else we cache) get the .info cache first. This will populate the info cache if it isn't, and we get to skip iterating through the commit ancestry to find the first commit affecting the file if it is. I think this is probably good no matter what other things we might cache. (as long as .info remains a WikiPage property, I'm no longer convinced that even makes sense. calling it .history[0] makes more sense to me, see #148)
  2. Just cache the history property like .info and .data currently are. This would mean the history cache gets cleared after every commit to a given file though.
  3. Instead of 2, make a smarter history cache, probably in the form of a list such that we can keep the history up to the tail cached, and just search for new commits until we get to the last found one to update it. I'm not sure if this complexity is worth it though, or what level of caching is warranted, given that I don't think history view is a thing that gets accessed a whole lot.
  4. Make the history view paged, only calculate the history up to the page limit (and cache it), then if page 2 is accessed, continue calculating from the last item. Splits up load times between page views that way. Would also mean that the view isn't hard locked to latest 100 commits like now.
gazpachoking commented 8 years ago

I just pushed a bit messy draft. It works fairly nice, doing pagination of history with lazy loading and caching of each page. I think I'll remove WikiPage.info in that branch too, if there are no objections to #148. The code is slightly more complex than I would have wished, let me know any comments.