[pgrouting-dev] Non-scheduled Routing algorithm
Stephen Woodbridge
woodbri at swoodbridge.com
Mon Jun 13 15:25:40 EDT 2011
On 6/13/2011 1:28 PM, Kishore Kumar wrote:
> Hi,
>
> I am facing the following issues in the prototype code[1]:
>
> 1. As I am internally calling Dijkstra function and the Dijkstra
> implementation assumes that vertex id and edge id are integers but
> according to GTFS, stop id and route id can be text also. This can be
> solved by:
> a. Generating a new table that maps Auto-generated integers to Stop
> Ids(Map<Integer,Text>)
> b. Modifying Dijkstra implementation to accept vertex id of type text
I think I would do a. above. The reason is text id's are really for
people and and integer id's computers like. And it is likely that doing
b., you would need to remap the text labels to integer anyway for
performance reasons.
> 2. Since the non-scheduling algorithm is not directly doing any lower
> level calculations, I implemented the prototype using PL/pgSQL
> language. Is rewriting the same logic in c is required and does it
> provide any significant performance boost? According to a post in
> pgsql-performance list[2], "I wouldn't expect the queries called by
> the pl/pgsql function to be much faster if called through SPI from C
> instead.". Hence, my current thought is to give real-life data as
> input and check for performance problems and if performance is bad,
> write the code in c.
I do not have direct test experience to back this up, but assuming pgsql
as a language is implemented similar to Perl or python the standard is
to compile the source to bytecode and then run a bytecode interpreter.
This gives very good perfomance when 90% of the time is spend in library
functions that really are compiled C/C++ and called from the
interpreter. Where you start to run into performance problems is when
you have a lot of code or a lot of looping and evaluating expressions.
That said, the rule for optimizing code is to measure first and then
remove the worse bottle neck, and then repeat until you are happy with
the results. So I see no problem with a prototype in pgsql, and later it
or part of it can be rewritten to C if there are performance issues.
Hope this helps,
-Steve
> Thanks& Regards,
> J Kishore kumar.
>
> [1] - https://github.com/pgRouting/pgrouting/blob/gsoc-multimodal/extra/transit/sql/nonscheduled.sql
> [2] - http://archives.postgresql.org/pgsql-performance/2010-05/msg00199.php
>
> On Sun, Jun 12, 2011 at 1:30 PM, Anton Patrushev
> <anton.patrushev at georepublic.de> wrote:
>> Hi Kishore,
>>
>> Ah, now I got it. Well, here in Russia some bus routes also don't have
>> fixed schedule and are regulated by number of buses/trips. Thus I
>> think the idea makes sense.
>>
>> Anton.
>> _______________________________________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
More information about the pgrouting-dev
mailing list