On Dec 18, 2014, at 12:48 PM, Stephan Beal <sgb...@googlemail.com> wrote:
> i suspect that some of the lower-hanging fruit, like truncating the UUIDs, > would initially give us bigger wins with less effort. Yes, I thought that went without saying. I would have mentioned it in my first email, only I didn’t know if Fossil would accept truncated UUIDs in that particular context. There is one other way to solve it, which would let you keep the tree view without spamming the client with the entire tree on the first /tree page load: Ajax. That is, on the initial page load, send only the HTML necessary to render the initial view: the root and the first level of files. Then on each click that requires an unfolding of that sub-tree, send an XHR request back to the Fossil server for that sub-tree’s file list. That would be a considerable amount of work, of course, but it would noticeably speed things even for smaller trees than the NetBSD one Martin Gagnon is letting us play with. My largest tree here takes 175 ms to generate and nearly 200 ms to arrive over the network. This is slow enough to be noticed by a human. You want to get below about 50-100 ms. Speaking of latency, if you are thinking of objecting that the XHR requests would add noticeable latency vs the current scheme, where all the data is already present and just has to be displayed, I speak from experience when I tell you that you can get an XHR round-trip time down into that double-digit millisecond range. More speed simply isn’t necessary when dealing with human reaction time. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
