Memory consumption increases exponentially and crashes app on iOS.

[JeremyRoberts2]

We have found that when at least one feature is selected on a FeatureLayer in a MapView, and that Mapview is resized, memory consumption exponentially increases and is never release. On iOS this results in the app crashing quite quickly. This is happening in version 100.7 of Qt runtime SDK. It does not appear to happen in 100.5. The memory consumption does continue to increase on Windows as well, but Windows appears to handle it better and prevent the app from crashing.  On Mac it seems like the memory is fine.  So it is critical, to see this problem crash the app, to run it on iOS.  I have created a sample Qt Quick based app to demonstrate.  This app uses a public ESRI layer and has two map views (as our own app does).  If you drag the bar in the middle up and down and therefore resizing the map view, the app will quickly consume all memory until crashing.  It is also critical that a feature is selected.  The out of control memory consumption does not appear to happen if no features are selected.  I have auto-selected a feature at app startup in this demo app.  Let me know if you have any questions or have any suggestions 🙂

Thanks!

Jeremy

[JamesBallard1]

Hi @JeremyRoberts2 ,

   Thanks for reaching out the Qt team, and especially thank you very much for the excellent reproducer app. That was a big help in looking into the problem.

I can reproduce the issue with 100.7 and 100.8, but not 100.9. Are you able to try the 100.9 release and see if the problem is still happening for you?

Please let me know if 100.9 works for you.

[JeremyRoberts2]

I can confirm that it looks like 100.9 does not exhibit the issue.  So that is good.  Our problem though is that it appears 100.9 has a different issue which is making us hesitant to upgrade.  Please see this post from my colleague who works on the same app...

https://community.esri.com/t5/arcgis-runtime-sdk-for-qt/tile-based-feature-requests-for-extent-any-w...

I'm worried getting rid of one issue by upgrading, will introduce another issue in our app 🙂 mostly due to the number of requests being queued up and therefore the overall time to return an identify taking longer (since it is behind a large queue).

 Any other suggestions?

[JamesBallard1]

@JeremyRoberts2 ,

I hear your concerns. I can tell you that we have some enhancements planned for the next release that should alleviate the issues related to the feature tiling requests getting queued up, resulting in worse performance.

I am looking forward to getting the Update 10 release into your hands so both of these issues are resolved for you.

[JeremyRoberts2]

@JamesBallard1,

Thanks for the reply!  We will be anxiously awaiting 100.10 🙂

Given that our iPad users are essentially locked into one of the old versions of our app, because of this memory issue (and also the 100.9 issue), do you happen to know if there is any work-around we can implement on our side with 100.7?  As in, is there maybe a config file that can be tweaked after installing the SDK on our machines, or is there a setting on our ArcGIS servers or feature layers that might override whatever is causing 100.7 to consume memory?  Or anything like that?  Just curious.  Likely it is a more significant issue where the fix can only be required with an SDK code change, but I thought I'd ask just in case there was something we could do on our side to hold us over until 100.10.

Thanks!

Jeremy

[JamesBallard1]

@JeremyRoberts2 ,

  Unfortunately I do not know of any SDK or server changes you can make with 100.7 to work around that memory issue.

We are working hard on Update 10 to get that out to you soon!

[JeremyRoberts2]

Hi James!

We downloaded 100.10.  Initial tests appear to show the memory issue is fixed.  We will continue testing this. 

It appears as though the feature tiling requests getting queued up and causing worse performance in our queries, because they get slapped at the end of the queue, is still there.  In our case we can pan the map a few times, and then try to query a feature and it takes 13 seconds to return that single query because it has to wait for the huge pile of tiled based requests to finish.  Was there anything ESRI was able to implement in 100.10 to help alleviate this issue?  Is there a flag or something we can define locally to turn off tiled based requests now?

Thanks!

[JamesBallard1]

Hi @JeremyRoberts2 ,

I am pleased to let you know that yes, we did add something at 100.10 to alleviate this issue for you.

https://developers.arcgis.com/qt/qml/api-reference/qml-esri-arcgisruntime-loadsettings.html 

On the LoadSettings object, which you can set on a web map prior to loading it, you can set the featureTilingMode now. If you specify Enums.FeatureTilingModeDisabled, then feature tiling will be disable entirely in your map for all feature layers.

[JeremyRoberts2]

This is great news!  We will try it out.

Thanks!