Consider simplifying shapes in parallel #3
Comments
jerluc
added a commit
that referenced
this issue
Jun 18, 2019
In running performance tests, I've found that contrary to the suggestions made in #3, the better solution in most cases is to not do shape simplification at all, which reduces CPU loads at the cost of network payload size (since the result is technically higher-fidelity vector geometries). That said, this has the practical advantage of reducing latency on higher-bandwidth network connections, by relying more heavily on network optimizations (caching, compression, etc.).
jerluc
added a commit
that referenced
this issue
Jun 18, 2019
In running performance tests, I've found that contrary to the suggestions made in #3, the better solution in most cases is to not do shape simplification at all, which reduces CPU loads at the cost of network payload size (since the result is technically higher-fidelity vector geometries). That said, this has the practical advantage of reducing latency on higher-bandwidth network connections, by relying more heavily on network optimizations (caching, compression, etc.).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, after the ElasticSearch documents are deserialized as
orb.Geometry's, the features all get compiled into a single layer and bulk simplified. This makes life easier, however, the layer/feature collection bulk simplification process runs serially, which may have some effects on performance.We should consider instead using the
DouglasPeuckerSimplifier.Simplify(orb.Geometry)function to allow us to simplify each geometry potentially in parallel, by using a pool of goroutines.The text was updated successfully, but these errors were encountered: