ucdavis/wayfinding — pull request #14 by japorito (2014-04-10 05:24:51+00:00)
Title: Performance Improvements for Routing and Routing Immediately on Page Load

Route on page load:
===
Specifying an endpoint in the initialization call to wayfinding causes the plugin to show the route to there immediately when the page loads. For consistency with startpoint, this supports being passed as either a string with the ID of the destination, or a function which returns the ID.

Performance enhancements in routeTo:
===
Prior to this commit, when routeTo was called, it generated the shortest path to every place in all the maps (but from only one start point) and then discarded that information and started over with the next routeTo. This commit saves that data, unless a) the startpoint is changed or b) the accessibility option is toggled. Both of those conditions invalidate the dataStore path metadata, so it needs to be regenerated.

The performance increase with this is dramatic. After the paths are generated, routing to anywhere is near instantaneous, even on our large maps. Before it would take a few seconds to complete. You only have to pay this penalty on the first routeTo. Alternatively, if the client supplies a dataStore cache which already has path metadata for the specific startpoint they initialize it with, they can set option.wayFound to true in the initialization, and avoid that initial several seconds of cost altogether.

QUESTION: I could make it initialize the dataStore cache with the path metadata on the initial page load. For large maps (such as ours) this adds a significant (~4.5 s) delay to the initial page load time, but then all routing operations are instantaneous. Is it better to have that delay then, or on the first routing operation, from a UX perspective? Should I make it client configurable?