37151213cd
The existing architecture serializes all cards and revlog entries in the search range into a protobuf message, which the web frontend needs to decode and then process. The thinking at the time was that this would make it easier for add-ons to add extra graphs, but in the ~2.5 years since the new graphs were introduced, no add-ons appear to have taken advantage of it. The cards and revlog entries can grow quite large on large collections - on a collection I tested with approximately 2.5M reviews, the serialized data is about 110MB, which is a lot to have to deserialize in JavaScript. This commit shifts the preliminary processing of the data to the Rust end, which means the data is able to be processed faster, and less needs to be sent to the frontend. On the test collection above, this reduces the serialized data from about 110MB to about 160KB, resulting in a more than 2x performance improvement, and reducing frontend memory usage from about 400MB to about 40MB. This also makes #2043 more feasible - while it is still about 50-100% slower than protobufjs, with the much smaller message size, the difference is only about 10ms. |
||
---|---|---|
.. | ||
added.ts | ||
AddedGraph.svelte | ||
AxisTicks.svelte | ||
buttons.ts | ||
ButtonsGraph.svelte | ||
calendar.ts | ||
CalendarGraph.svelte | ||
card-counts.ts | ||
CardCounts.svelte | ||
CumulativeOverlay.svelte | ||
ease.ts | ||
EaseGraph.svelte | ||
future-due.ts | ||
FutureDue.svelte | ||
graph-helpers.ts | ||
graph-styles.ts | ||
Graph.svelte | ||
GraphRangeRadios.svelte | ||
graphs-base.scss | ||
GraphsPage.svelte | ||
histogram-graph.ts | ||
HistogramGraph.svelte | ||
HourGraph.svelte | ||
hours.ts | ||
HoverColumns.svelte | ||
index.ts | ||
InputBox.svelte | ||
intervals.ts | ||
IntervalsGraph.svelte | ||
NoDataOverlay.svelte | ||
RangeBox.svelte | ||
reviews.ts | ||
ReviewsGraph.svelte | ||
TableData.svelte | ||
today.ts | ||
TodayStats.svelte | ||
Tooltip.svelte | ||
tooltip.ts | ||
tsconfig.json | ||
WithGraphData.svelte |