nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

SliderTest.zip

locate.png

Encontre mais publicações marcadas com

Accepted answers

All comments

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-way-to-revert-to/m-p/184867/highlight/true#M899

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

MikeMillerGIS_0-1645117474312.png

SarahHartholt_2-1645117653353.png

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!

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.