Hi, Spring engine developer here peeking over the garden walls to a fellow RTS project. While profiling 0AD I noticed certain functions relying on SpatialSubdivision::Get{Near,InRange} showed up alarmingly often and consumed much more CPU than seemed justified from the functionality provided by them. After quickly diving into your codebase I discovered that SpatialSubdivision::GetInRange calls make_unique on its SpatialQueryArray argument, which in turn issues a std::sort followed by a std::unique (!) just to handle the problem of buildings spanning multiple subdivision tiles. This is an *extremely* heavy-handed way to avoid duplicate entity ID's, not to mention a textbook case on how to kill performance since spatial queries are one of the most frequently executed (certainly in Spring's case) and hence time-critical parts of any RTS engine. So I fixed it, following the old adage that 99% of computing is an exercise in caching: 0AD-SpatialSubdivisionPerfPatch-v3.diff This trades O(n log n) time for O(n) space which I would consider an acceptable deal since space is generally cheap but time almost never is. However, it also introduces a bit of double bookkeeping in SpatialSubdivision, which may not be to everyone's taste. Either way, with these changes the relevant functions dropped to neglible percentages, so I'm calling it an hour well spent. (AFAICS no calling code actually cares about the ID's being sorted, nor should it) This patch was created against commit d14b8363fcd143d43a4888e7126e97fddf0015ab of your git mirror (sorry, not touching svn with a ten-foot pole), and is small enough that it shouldn't present any difficulty to apply. ps: if there's still a need, I might also be tempted to take a look at your pathfinder issues... for a price