After using LineTo and Fill a bit with some real data, I've noticed that these methods slow down quite a bit depending on the resolution being used and the distance/size of the geometry that we're attempting to generate cells for. e.g. the following shows the difference between resolution 10 and 14 for the Uber SF test polygon:
| Method |
Mean |
Error |
StdDev |
Gen 0 |
Gen 1 |
Gen 2 |
Allocated |
| 'pocketken.H3.Fill(sfPolygon, 10)' |
15.72 ms |
0.133 ms |
0.118 ms |
1500.0000 |
625.0000 |
312.5000 |
12 MB |
| 'pocketken.H3.Fill(sfPolygon, 14)' |
37,967.6 ms |
136.98 ms |
121.43 ms |
3001000.0000 |
664000.0000 |
12000.0000 |
24,961 MB |
Some of this is just going to come down to the fact that we're generating a lot of indexes, but, there's also a lot of conversion to/from/between H3Index and its corresponding center coordinate for the polyfill stuff, and to/from local IJK for the line. Need to spend some time looking at optimizing and reducing allocations along those code paths to see if there's an opportunity to improve performance when using higher resolutions over larger areas.
After using
LineToandFilla bit with some real data, I've noticed that these methods slow down quite a bit depending on the resolution being used and the distance/size of the geometry that we're attempting to generate cells for. e.g. the following shows the difference between resolution 10 and 14 for the Uber SF test polygon:Some of this is just going to come down to the fact that we're generating a lot of indexes, but, there's also a lot of conversion to/from/between
H3Indexand its corresponding center coordinate for the polyfill stuff, and to/from local IJK for the line. Need to spend some time looking at optimizing and reducing allocations along those code paths to see if there's an opportunity to improve performance when using higher resolutions over larger areas.