Nautical Chart Indexes

Hi Kev,

After we dig into the code further, we have made more improvements in memory and performance for BuildIndex method. Now we can keep the memory stable and under a reasonable/accept level. For performance, we improve some by increasing the usage of CPU. Here is the new test result on our side. The latest version is 11.0.0-beta012.

US4FL12M.000 (0.25Mb):
Time (11.0.0-beta010): 4.81s
Time (11.0.0-beta011): 3.1s
Time (Latest): 2.25s

Peek Memory (11.0.0-beta011): 0.04GB
Peek Memory (Latest): 0.02GB

Peek CPU (Latest): 39%

US5FL49M.000 (0.47Mb):
Time (11.0.0-beta010): 10.369s
Time (11.0.0-beta011): 4.059s
Time (Latest): 4.32s

Peek Memory (11.0.0-beta011): 0.06GB
Peek Memory (Latest): 0.03GB

Peek CPU (Latest): 59%

US4FL18M.000 (1.04Mb):
Time (11.0.0-beta010): 69.665s
Time (11.0.0-beta011): 13.116s
Time (Latest): 42.4s

Peek Memory (11.0.0-beta011): 0.17GB
Peek Memory (Latest): 0.07GB

Peek CPU (Latest): 83%

US3GC06M.000 (1.49Mb):
Time (11.0.0-beta010): 181.173s
Time (11.0.0-beta011): 61.167s
Time (Latest): 57.7s

Peek Memory (11.0.0-beta011): 0.49GB
Peek Memory (Latest): 0.11GB

Peek CPU (Latest): 90%

US4FL14M.000 (2.40Mb):
Time (11.0.0-beta010): 339.822s
Time (11.0.0-beta011): 37.4s
Time (Latest): 122.9s

Peek Memory (11.0.0-beta011): 0.37GB
Peek Memory (Latest): 0.18GB

Peek CPU (Latest): 91%

US5AK4JM.000 (4.97Mb):
Time (11.0.0-beta010): 695.392s
Time (11.0.0-beta011): 230.263s
Time (Latest): 319.5s

Peek Memory (11.0.0-beta011): 0.84GB
Peek Memory (Latest): 0.37GB

Peek CPU (Latest): 94%

Maybe you are curious why we have to build the .hyr file, according to the .000 file. Here are the reasons:
• ThinkGeo Nautical Charts SDK strictly follows the specification from IHO https://www.iho.int/iho_pubs/draft_pubs/S-52_e6.1.0/S-52_e6.1.0_and_PresLib_e4.0.0.htm. It’s rich in the symbols and you can easily to switch between different modes, show or hide different features, according to your requirements. To support so many different, complicated but colorful symbols, all are calculated and drawn on the fly, thus performance consumed. So we analysis all features in the *.000 and create the drawing instructions of each feature in BuildIndex method, there it has some geometry processing codes, so a bit slow when building the index, but the good news is that you will experience a pretty good drawing performance when showing them up in the application. You just need to build the index only once. I’m not sure whether you tried the same product from ArcGIS, we have a much better drawing performance.

Regards,

Vincent