Reducing the number of allocations is more of a level-design choice, than one of programming. In this case, removing the Tile allocation is not an option, as it is the most essential data structure required to render a game level. Opening up Tile.m in the Xcode editor, you can see its 183 bytes are composed of a few handfuls of primitives, most notably, arrays of size kNumberOfLayers which in this run was equal to 7.
#Ios memory monitor code#
This allocation is 19.7% of the app's total memory footprint.įor this allocation type, viewing the line of code it sources from is less interesting than considering its overall size and number of repetitions. Though each Tile is relatively small (183 bytes), there are 41,900 instances in memory at one time and that composes a total of 7.67 MB. The second largest allocation made by the app is the Tile class.
Next, let's have a look at the second largest allocation.įigure 10 – The next allocation is "Tile".Ĭlick the Allocation Summary breadcrumb to return to the results pane. Noticing that the size of the allocation is a factor a TileSet's number of tiles, numTiles, now is good time to consider whether extra tiles in the TileSet could be removed. KNumberOfTileSlices controls the number of image masking options to shape a tile if some of the shapes are used less often, the developer could consider removing the lesser used options.Īlternatively, the developer can look into reducing the size of the allocation. Having observed that the malloc effecting the allocation is repeated kNumberOfTileSices times, the number of allocations can be reduced if kNumberOfTileSlices can be reduced. The developer should consider switching to image-based masking, and then profile to assess the new speed-versus-space trade off.Īll 34% of the memory footprint can be saved for levels not using image masking if a flag is used to prevent these placeholder allocations in those cases.įor levels that do use masking, the developer might consider reducing the number of allocations. This geometry-based form of image masking was created with the intention of being incredibly fast at runtime, which it would be if the memory required to support it were not so large. Given this information, consider the following approaches to minimize this allocation: This line of code is responsible for a feature called "tile slices," a rudimentary geometry-based form of image masking. Line 348 is a different allocation, and at 1 KB, it pales in comparison and can be ignored for the time being.īecause this allocation accounts for 34% of the app's total memory, it's a single line of code that offers the largest opportunity to minimize memory usage. It is responsible for 12.56 MB of this type of allocation. Source code is not shown for allocations made within a framework or static library, though you can still weigh the memory cost of a library call and decide to throttle use or consider a replacement.įigure 9 – Line of code where the allocation occurs. Note: You're only able to see code for sources for your app. These two events were chosen because they allocate a majority of the total memory used by the app, and therefore, they are also the best candidates to speed up.
The range shown here includes allocations for a game's intro screen and loading the first level. Doing this filters the results shown on the Allocations Summary below.įigure 1 – Hold the Command key and click from areas marked 1 to 2 in order to select the range of interest.įigure 2 – Include in the range ramps that represent allocation. Select a range spanning the time within the run you want to analyze. Use the app for a few minutes to allow Instruments to retrieve a representative sample of data. Navigate to the area of the app that you're interested in assessing memory usage, such as the main level of a game, or the primary editing operations of an image editing app. Back to Top Profiling the app for memory usage
0 kommentar(er)
