Is there a known fix or workaround (or upcoming patch) for broken service feature table caching in QML?

[JonathonGrivas]

Right now, using Qt 5.7.1 and ArcGIS Runtime SDK v100, none of the caching modes seem to work on a service feature table. This means every interaction with the map is querying and then re-rendering hundreds or even thousands of features and it makes my application vastly inferior to ones made with any other technology.  Is there any fix or workaround for this? 

[LucasDanzinger · Accepted solution]

Ian-

We plan on improving the caching behavior and also improving the way we request features so as to reduce the overall network payload for our Update 2 release. This should give you the performance gains that you are requesting. Update 1 will be released in the next few weeks, and Update 2 is planned for the end of the year.

However, just to provide some clarification, we believe that while there are areas for improving the efficiency and performance of the feature table, it is currently working as it was designed to work. This is the reasoning provided in a bug report that I believe you submitted: "The OnInteractionCache feature request mode is currently working as designed. One of the main reasons network requests continue to go out is because data could be changing on the server due to edits from other users. Limiting these requests could result in the features cached on your device to become out of date. The fact that this feature request mode contains the word "cache" may suggest that there are performance optimizations. However, while this specific mode may have some performance gains over the OnInteractionNoCache mode, which requests new features with every viewpoint change, the main benefit of using this mode is that it works well in partially connected scenarios. For example, if you lose network connection, you will still have features cached to your device, and you can continue doing your work. If you are needing to fine tune the amount of network requests that go out, you could consider the ManualCache mode, which gives you complete control over each request that is sent to the server. This mode works especially well when working in a small area, and when other users are not updating the features you are working with.

While this feature request mode is currently working as designed, we are continuing to look into ways to further optimize feature requests with the ServiceFeatureTable in an upcoming release"

If you have specific ideas on how you would like to see this improved, I would be interested to hear from you so that I can share your feedback with the team.

- Luke

[JonathonGrivas]

Thank you Lucas,

I was unable to ever find the response to my bug report submission, so thanks for sharing it.

FeatureRequestModeManualCache seems to behave no differently for me than FeatureRequestModeOnInteractionCache. In both modes, every pan and zoom event on the map re-queries the current extent. Additionally, both modes seem to do some heavy processing and/or re-rendering on every query response because both modes trigger massive CPU spikes, introduce UI lag, and cause the layers to flicker if there are multiple layers visible and more than maybe 100 features on screen.  The two separate modes performing identically strikes me as a bug, but maybe there's something I'm missing that is different between them.

As a side note, and probably unrelated to the featureRequestMode property:

In the JS API I'm able to query literally the entire feature set from every single feature service, render all of them on screen as separate feature layers, and begin smoothly interacting with the map faster than I can do this with just one of my somewhat large feature sets in the QML SDK. Even if I request all of the layers and features in the image below on every single pan with the JS API, it still performs more smoothly and utilizes less cpu than panning even a single layer on the QML.  I am aware this is unrelated to the feature request mode, but this poor performance showcases why I am so concerned about "feature caching", because if the SDK has to re-request even a single layer with a few hundred features, performance in the app drops off a cliff.   If this performance somehow gets fixed soon then feature caching wouldn't be quite as important to me anymore. 

Thank you, as always, for your effort in responding to me! I really appreciate the assistance. 

[LucasDanzinger]

FYI here is the bug. I am not sure why you did not get a notification about the status update - BUG-000101117: The on interaction cache feature request mode of the.. 

As for the InteractionCache vs ManualCache modes being the same, that is very strange. If you look at the Sample Viewer, there is a sample in the Features section that displays the behavior of ManualCache. It does not request any features until the populate button is clicked. Is that not what you are seeing?

Regarding the CPU spikes, can you upload a sample project with steps to reproduce. I tried running through a small subset of feature layer tests we have for feature services, and I did not see CPU spikes, so I'm definitely doing something different than you.

Thanks,

Luke

[JonathonGrivas]

Lucas,

Thanks for the quick response.  Could you possibly point me towards the REST service for some demo feature sets that are publicly visible and have a large number of features?  I probably shouldn't share my feature sets to make a demo for you as the data belongs to paying clients. 

[LucasDanzinger]

Most of our public services get periodically cleaned up/reset. This one has a decent amount but by no means is a large dataset - Sync/WildfireSync (FeatureServer) 

We test with larger internal datasets and services. Maybe you could export a copy and anonymize any data, and private message me the data so we can stand it up on our services? There's lots of combinations that could contribute to the performance issues you are seeing (geometry type, geometry complexity, number/size of attributes, symbology/renderers, labels, etc), so it might be easiest to use data (or similar data) that you are already seeing issues with.

[JonathonGrivas]

I am going to share the dataset with you in a private message.  I don't have time to create a stripped down demo right now, but I'll work on that. If you just want to try it yourself, the layer that has the most data there I think is the layer named "Storm Manholes", though on the JS api version we can smoothly use the map with all 7 feature sets added as individual feature layers. 

[_____]

//

[LucasDanzinger]

Hah, my bad! Sorry about that Jonathon...