Performance bottleneck in the spatial abstraction: getting the neighbourhood is extremely expensive

[metaphori]

Originally reported by: Roberto Casadei (Bitbucket: metaphori, GitHub: metaphori)

---

Simulation configuration:

• 1000 nodes
• Communication radius: 0.05 (only a handful of neighbours for each node)
• Program: classic gradient

The GUI is largely freezing, losing substantial reactiveness and almost any capability to show progress in the computation.

Screenshots from CPU sampling in VisualVM clearly points out the reason:

---

• Bitbucket: https://bitbucket.org/scafiteam/scafi/issue/10

[metaphori]

Original comment by Roberto Casadei (Bitbucket: metaphori, GitHub: metaphori):

---

We may take a look at the following

• https://en.wikipedia.org/wiki/Spatial_database#Spatial_database_systems For a list of spatial DB systems
• https://en.wikipedia.org/wiki/Spatial_database#Spatial_index For a list of spatial indexes
• Neo4J Spatial: https://github.com/neo4j-contrib/spatial
• PostgreSQL with PostGIS: http://postgis.net/
• Neo4J vs PostGIS: http://www.gdmc.nl/publications/2012/Neo4j_versus_PostGIS.pdf
• Redis with GEO API: https://redis.io/commands/#geo
• SpaceBase: http://blog.paralleluniverse.co/2012/03/21/introducing-spacebase-a-New-Realtime-Spatial-Data-Store/

[metaphori]

Also, take a look at: http://tile38.com/

• Tile38 is an open source (MIT licensed), in-memory geolocation data store, spatial index, and realtime geofence. It supports a variety of object types including lat/lon points, bounding boxes, XYZ tiles, Geohashes, and GeoJSON.
• Tile38 uses the Redis RESP protocol natively. Therefore all clients that support basic Redis commands will in turn support Tile38