Databases
StackOverflow2013
Postsdbo
POGMSPolyline very large memory spike
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POGMSPolyline very large memory spike
    primarykey
    data
    text
    <p>In a GPS app that allows the user to display a list of complex location points that we call tracks on various different types of map, each track can consist of between 2k to 10k of location points. The tracks are copiously clipped, pruned and path-simplified when they are rendered on non-Google map types. This is to keep memory usage down and performance up. We typically only wind up submitting far less than a thousand (aggregate) transformed location points to the OpenGL pipeline, even in the worst cases.</p> <p>In integrating the Google Maps SDK for iOS, we initially attempted to continue to leverage our own OpenGL track rendering system, but ran into issues with conflicting OpenGL context usage (rendering worked, but we couldn't get GMSMapView to and our own internal OpenGL resources to both release without someone touching deleted memory). </p> <p>So we are trying to leverage the GMSPolyline constructs and just let the Google SDK do the track rendering, but we've run into major memory usage issues, and are looking for guidance in working around them.</p> <p>Using Xcode Instruments, we've monitored memory usage when creating about 25 poly lines with about 23k location points total (not each). Over the course of poly line creation, app memory usage grows from about 14 MB to about 172 MB, a net peak of about 158 MB. Shortly after all the poly lines are created, memory usage finally drops back down to around 19 MB and seems stable, for a cumulative net of around 5 MB, so it seems each location point requires around 220 bytes (5 MB / 23k points) to store.</p> <p>What hurts us is the peak memory usage. While our laboratory test only used 23k location points, in the real world there are often many more, and iOS seems to jettison our application after <em>Google Maps</em> has consumed around 450 MB on an <em>iPhone 5</em> (whereas our internal poly line rendering system peaks at around 12 MB for the same test case).</p> <p>Clearly the <code>GMSPolyLine</code> construct is not intended for the heavy weight usage that we require.</p> <p>We tried wrapping some of the poly line creation loops with separate autorelease pools, and then draining those at appropriate points, but this has no impact on memory use. The peak memory use after the poly lines are created and control is returned to the main run loop didn't change at all. Later it became clear why; the Google Map system isn't releasing resources until the first DisplayLink callback after the poly lines are created. </p> <p>Our next effort will be to manually throttle the amount of data we're pushing at GMSPolyline, probably using our own bounds testing, clipping, pruning &amp; minimization, rather than relying on Google Maps to do this efficiently. </p> <p>The drawback here is that it will mean many more GMSPolyline objects will be allocated and deallocated, potentially while the user is panning/zooming around the map. Each of these objects will have far fewer location points, yet still, we're concerned about unforeseen consequences of this approach, hidden overhead of many GMSPolyline allocs and deallocate.</p> <p>So the question is, what is the best approach for dealing with this situation, and can someone from Google shed some light on any <code>GMSPolyline</code> best practices, upper bounds, bottlenecks, etc. ?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USKnickerless-Noggins
    1. USDS99
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. POGMSPolyline very large memory spike
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POGMSPolyline very large memory spike
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POGMSPolyline very large memory spike
      1. USachi
      1. VTFavorite
    1. COThe team is going to investigate this. I will respond when I have an update for you.
      singulars
      1. POGMSPolyline very large memory spike
      1. USskarE
    2. COFWIW we tried throttling our GMSPolyLine submission, and even pre-pruning each poly line to less than 1000 points. With throttling enabled, we submit each poly line 50ms apart (tried other intervals as well). But the memory spikes persist, as it seems 2 - 3 seconds go by before the GMS framework begins to release memory. So this approach does not look promising.
      singulars
      1. POGMSPolyline very large memory spike
      1. USDS99
    3. COAlso, we attempted to do our own bounds testing, and screen space clipping, so that we were submitting many more, albeit significantly smaller in point-count, GMSPolyLines. However this approach means we're releasing, re-clipping, then re-adding many poly lines each time the [GMSMapViewDelegate didChangeCameraPosition] callback fires. The performance hit is way too much, because clipping requires us to transform Many points to screen space using [GMSProjection pointForCoordinate], then clip, then break into multiple poly lines & resubmit coordinates.. a bit of a mess.
      singulars
      1. POGMSPolyline very large memory spike
      1. USDS99
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload