Memory consumption increases exponentially and crashes app on iOS.

119
5
a week ago
Highlighted
New Contributor III

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

Tags (4)
Reply
0 Kudos
5 Replies
Highlighted
Esri Contributor

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.

Reply
0 Kudos
Highlighted
New Contributor III

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?

Reply
0 Kudos
Highlighted
Esri Contributor

@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.

Reply
0 Kudos
Highlighted
New Contributor III

@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

Reply
0 Kudos
Highlighted
Esri Contributor

@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!

Reply
0 Kudos