ThinkGeo.com    |     Documentation    |     Premium Support

Memory usage in iOS v12 + a few other issues

#1

After upgrading to v12 from v10 we are seeing a significant amount number of jetsam events that are closing our application. We are running our test on an IPAD 6th gen with basically nothing else installed or running but our application. After relatively few view operations the jetsam logs get generated. I have duplicated a similar issue with the SQLite layer in the howDoI sample code – although it takes much more view operations before the app is closed. Our particular test case employs about 32 SQLite feature layers.

I added some simple memory tracking code into the application – managed memory appears very consistent between the v10 and v12, however the native memory is significantly different.

Taking a snapshot of mem usage prior to initial update the native memory usage in v10 is
258.25 MB
After initial map update it is
298.16 MB
Free Memory 78.66

For v12 mem usage prior to first update is
290.03 MB
after initial map update it is
467.88 MB
Free 18.27 MB

These numbers do represent the worse case scenario where all featues are visible. They are also numbers from when the app is built in debug. Only significant difference between the two versions is that one is using BingmapsLayers and the v12 version is using the overlay.
Numbers are relatively consistent over multiple runs. As mentioned the increased memory usage has proven to be significant problem which may forces us back to using v10 again.

v13.0-168 has introduced some redrawing issues over v13.0-167. When zooming in the map the display zooms immediately on the existing image that is displayed – the underlying features are redrawn and the old image is supposed to go away – that is no longer occurring the older enlarged feature display remains. Linear layers show this issue readily.

one piece of functionality that we have is the ability to zoom into a selected features bounding box. When we do this the base map goes away. Scale at bottom of the map indicates 50 feet for a frame of reference – v10 with bing layers does not have this issue.

When requesting a feature layer to be redrawn all features in the layer are getting refreshed instead of just the one. In this case all of the layers involved are in the same overlay.

#2

Also I added a refresh button to the mix to see if there is likely a memory leak – expectation would be the memory stays pretty much the same since the extents/scale aren’t changing. This is a little bit less clear cut as the memory does fluctuate a bit when iOS reclaims some – but the used memory is increasing when hitting the refresh button.

Again all of these memory issues I am referring to are native memory as opposed to the managed memory.

#3

Thanks Richard,
Could you send you modified how do I sample. We could look into more detail.

Thanks

Frank

#4

Attached is a v12 test case – it only has the bing maps overlay loaded. v10 vs v12 for this test case only has about a 15MB difference on initial map load – not feature layers are included. By simply using the view control and pinch/zoom operations I can get the application within 5 minutes – this particular crash is not the jetsam event but is still problematic.

What this test case is meant to show is what appears to be a memory leak in native code – managed code does not appear to be an issue. Now on a panning operation I would expect the memory usage to remain relatively stable – instead it continually climbs. It does seem to plateau at a certain point and occasionally drop depending on what the view operation is and how much of the bing map is displayed.

Keep in mind this is a simple test case --without any feature layers. If you add SQLite data sets to this you will likely see a significant increase of memory usage after initial display. quite a few of the feature layers we use in our product are linear layers with text associated with them. So we are in a situation of high memory usage – where each view operation as expected causes a memory usages spike while drawing, but does not fully return to the same levels after drawing. Eventually when of the drawing spikes causes iOS to terminate our application with a Jetsam log.
ThinkgeoTestCaseBack.zip (468.2 KB)
Following is a native library that we created to get memory usage info for the application.
libMemTracker.zip (3.2 KB)

#5

Hi Richard,

Thanks for your sample! We are on it right now.

Ben

#6

Hi Richard,

Please get the latest beta version (ThinkGeo.UI.iOS Beta141) and have another try. The memory usage is improved a lot. I tested with 40 mutlitile layer overlays with one SQLite layer in each of them, and it works fine without crashing. Of course it’s not a good practice to have so many overlays in a real application.

Also Rick said you guys also have issues in Android. Could you please make sure everything goes well on iOS on your side first and we can then move over to Android.

Thanks,
Ben

#7

Somewhat a miscommunication on overlays – we have maybe 4 different overlays with all of the SQLite layers residing in a single overlay. My initial impression is that it does seem a lot more stable though I have only done brief testing at this point. I will continue looking at this tomorrow as I got sidetracked by another issue.

The bing maps are now way off - an area that should show in atlanta is ending up in the arctic. Not sure when this was introduced, but it was not an issue with core 13.0.0 beta-167 and ios version 13.0.0 beta-125

#8

I was told you guys are using 32 SQLite layers, not sure how many overlays. I added 40 overlays just for a pressure test.

I’m now reviewing the code and 1, make sure it’s using async for drawing tiles so no blocking on the UI thread. 2, review all the Web Based layers making sure they are correct and performs good. There will be a new revision maybe today or early next week.

#9

Hi Richard,

Please try the latest version iOS 13.0.0-beta145, it is using async for drawing all the tiles and all web based layer/overlays has been reviewed and optimized. You will find the BingMaps is correct and even faster.

We are about to work on the Android version, let me know if you see any issues.

Thanks,
Ben

#10

I have another issue with the latest ios version 145 and 146 – I am getting an exception thrown : ‘Collection was modified; enumeration operation may not execute.’
This is occurring during the drawing of the feature layers. Prior to 145 this was not an issue.

#12

Can you show me your code and give me some guidance how to recreate this issue?

Also just FYI we’ve also reviewed the Android code and applied Async to it in the latest beta release, it’s much more responsive now.

#13

Might be best if I create a test case that replicates it – We load our layers based off of a database file that is brought down from a remote server – so layer creation is a bit convoluted. Display of layers is relatively straight forward though.

#14

So you feel it might be the longer it takes to load a layer, the easier it is to recreate this issue? So how long it takes for layer.Open() to run in your case, and you still have 32 SQlite layers open at the same time, right?

#15

We are using our own SQLiteFeatureLayer & source – we developed these items prior to the availability of the Thinkgeo one.

So I modified our code to use the Thinkgeo SQLite layers and feature source and had the same issue occur with that one as well.

In this latest case there were 2 SQLite layers both linear open at the same time. Problem is not with the open call – the problem occurs when drawing is in progress after the layers are already open. Only collection that I am aware of at this point in time is the collection of features.

I got sidetracked for a bit but will still get you a test case to duplicate this issue. There are a couple of other things I want to try first though.

#16

Sure. Just let us know when it’s ready. We are doing more test at the same time on our side as well.

#17

At this point I believe the problem has shown up as the result of the drawing code going to asynch, but I am fairly certain that it is somewhere in our code. I was not able to duplicate this in the test case I set up.

#18

Make sure to use the version V12.3. We made some more improvements in async drawing in that version.

The async issue is hard to debug. If you cannot duplicate it in a test sample, can you somehow make us available to run your app on our side, add us as a testflight tester or something? that would be helpful for us to understand the issue.

#19

I am running the latest betas 191 for core and 149 for iOS.
Didn’t even think to include this information before – here is the stack trace when exception is thrown. Knowing what collection it’s complaining about might tell me where to look.

0x0 in System.ThrowHelper.ThrowInvalidOperationException_InvalidOperation_EnumFailedVersion at /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/src/Xamarin.iOS/mcs/class/referencesource/mscorlib/system/throwhelper.cs:133,13	C#
0xFFFFFFFFFFFFFFFF in System.Collections.Generic.List<ThinkGeo.Core.Layer>.Enumerator.MoveNextRare at /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/src/Xamarin.iOS/external/corefx/src/Common/src/CoreLib/System/Collections/Generic/List.cs	C#
0xFFFFFFFFFFFFFFFF in System.Collections.Generic.List<ThinkGeo.Core.Layer>.Enumerator.MoveNext at /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/src/Xamarin.iOS/external/corefx/src/Common/src/CoreLib/System/Collections/Generic/List.cs	C#
0x1E1 in ThinkGeo.UI.iOS.LayerTileView.DrawAsyncCore	C#
0x6 in System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.InvokeMoveNext at
#20

Finally found the issue that was causing the Collection exception – we are adding an adornmentOverlay and scaleBarAdornmentLayer to the map. Here is the definition we are using for the layer and in case it matters the overlay and layer are added as one of the last steps in our process.

        ScaleBarAdornmentLayer scaleBarAdornmentLayer = new ScaleBarAdornmentLayer();
        scaleBarAdornmentLayer.Location = AdornmentLocation.LowerLeft;
        scaleBarAdornmentLayer.Thickness = 10;
        scaleBarAdornmentLayer.BarBrush = new GeoSolidBrush(GeoColors.Magenta);
#21

The issue has been recreated and working on it now. Thanks for helping us recreating the issue!