1) The main performance hangup was data transfer size. I improved the situation by, instead of fetching all proposal + opinion data all at once via fetch('/proposals'), now data can be fetched list-by-list (each focus). This allows us to be much more selective about which data to download. This will also allow for better responsivity for longer standing phased forums. Data from archival tabs won't have to be fetched.
2) The server was generating all proposal + opinion + pro/con data for a particular user every time someone accessed the forum. This led to significant lag and unnecessary computational effort, especially as forums increase in size. I improved the situation by caching proposal, opinion, and point data, and then post processing it for user-specific filtering on each request (see proposal.rb). I'm not a big fan of all the calls to Proposal.clear_cache sprinkled throughout the server code in order to invalidate the cache when some change is made, but it is what it is.
Client-side performance improvements include:
only run the histogram layout algorithm (and renderer) for histograms when it is in the viewport
don't generate a custom icon for users who didn't set an avatar. Instead, choose from a small number of icons (this made the biggest impact)
Client-side experience improvements include:
more use of loading indicators, especially for histograms whose data is being fetched and/or laid out
Two structural performance improvements:
1) The main performance hangup was data transfer size. I improved the situation by, instead of fetching all proposal + opinion data all at once via fetch('/proposals'), now data can be fetched list-by-list (each focus). This allows us to be much more selective about which data to download. This will also allow for better responsivity for longer standing phased forums. Data from archival tabs won't have to be fetched.
2) The server was generating all proposal + opinion + pro/con data for a particular user every time someone accessed the forum. This led to significant lag and unnecessary computational effort, especially as forums increase in size. I improved the situation by caching proposal, opinion, and point data, and then post processing it for user-specific filtering on each request (see proposal.rb). I'm not a big fan of all the calls to Proposal.clear_cache sprinkled throughout the server code in order to invalidate the cache when some change is made, but it is what it is.
Client-side performance improvements include:
Client-side experience improvements include: