Keep graph in Ram
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- cpp, postgresql
- Domain
- databases, performance
Research direction
The issue describes caching graph data in memory to avoid repeated database loads. Look at the pgRouting source code to understand how graphs are currently loaded from PostgreSQL and built into Boost C++ structures. Investigate the existing algorithm entry points and data structures to see where a caching layer could be inserted. Determine the memory footprint of typical graphs and design a cache lifecycle that works within the extension's architecture.
Written by the indexing model from the issue text.
Description
To optimize performance for large graphs, I have some ideas that could potentially improve the process. Currently, with every call to pgRouting, there is a time overhead for loading the graph from the PostgreSQL database and building the Boost C++ graph structure internally before running the algorithm.
My idea is to explore two possible approaches:
Keep the Graph in RAM:
It is possible to load the entire graph from the PostgreSQL database into RAM and keep it there during the lifetime of the application or API. By doing so, subsequent calls to the routing algorithm can directly access the graph data in memory, significantly reducing the overhead of loading the graph from the database each time.
Generate Boost Graph Structure in RAM:
If keeping the entire graph in RAM is not feasible due to size constraints, another approach is to generate the Boost C++ graph structure directly in memory and cache it for subsequent algorithm calls.
- Dominant language
- C++
- Stars
- 1.4k
- Forks
- 397
- Avg merge
- 2d 16h
- Merged PRs (30d)
- 8
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from pgRouting/pgrouting
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 3 days
-
Administrative Enhancement
Difficulty 1/5 Under an hour Newbie friendliness 80/100
Maintainers usually reply within 3 days
-
points_input Developers docPossibly taken @withaman69 claimed this 101 days ago. OpenC/C++ Developers Doc. good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
pgRouting/pgrouting#973 · 10 comments ·
Maintainers usually reply within 3 days
-
get_check_data developers docPossibly taken @withaman69 claimed this 103 days ago. OpenC/C++ Developers Doc. good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
pgRouting/pgrouting#972 · 7 comments ·
Maintainers usually reply within 3 days
All issues in pgRouting/pgrouting
Similar issues
-
std::fdim drops partial derivative w.r.t second argument in forward and reverse modePossibly taken @ADITYASINGH1206 claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 85/100
vgvassilev/clad#2534 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 61/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
HAP.cpp fixOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
ardia-browser/ardia#1942 ·
Maintainers usually reply within 1 day