Amar Pai wrote:
> So if I shard my graph into 3 parts, my main class can store them as
> class variables and they'll persist across requests? That would be
> great. But will I run into quota problems holding 3M data in memory?
> (Assuming low overhead otherwise, and only 100ish requests per day)
So if I shard my graph into 3 parts, my main class can store them as
class variables and they'll persist across requests? That would be
great. But will I run into quota problems holding 3M data in memory?
(Assuming low overhead otherwise, and only 100ish requests per day)
Also, if I did it that
There are 312 487 500 potential paths (25K choose 2) and edge weights
are variable-- the cost function is determined by user-configurable
multipliers. So precomputing all paths in advance isn't feasible,
unless I'm misunderstanding what you mean.
On Dec 27, 5:03 pm, "David Symonds" wrote:
> On
Using Djikstra's shortest path algorithm, you can compute the shortest
paths between all nodes in the same runtime as computing the path
between any 2 nodes, so storing then querying the precomputed paths
would be a good approach as mentioned above.
> Since there are no files in AppEngine, my fir
On Sat, Dec 27, 2008 at 5:16 AM, Amar Pai wrote:
> I have a route planning webapp, written in Python, that uses
> Djikstra's algorithm to find the shortest path between two nodes in a
> directed graph. I want to port this to AppEngine, but I'm not sure
> how to represent the graph. Right now I
