[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-07-27。"],[],[],null,["# Analyze memory efficiency\n\nAn app's memory usage characteristics are a fundamental aspect of its\nperformance. You can use the **System Profiler** to analyze these\ncharacteristics by looking at the available GPU counter information.\n\nAdreno devices\n--------------\n\nOn Adreno devices, start by first highlighting a period of time consistent with a single GPU frame as described in [Estimate CPU and GPU frame processing times](/agi/sys-trace/long).\nUse the technique described on that page involving the usage of the **GPU % Utilization**\nor similar counter track for your frame time boundaries as the counter tracks all use the same timing technique and will allow for more accurate estimates of memory utilization (compared to using the frame time boundaries derived from the GPU slices whose data is collected independently from the counter track data).\n**Figure 1.**Utilization track lining up with the relevant counters below it\n\n### Read/write totals\n\nOnce you've highlighted a single frame in the profiler, start by looking at the\n**Read Total (Bytes/sec)** and **Write Total (Bytes/sec)** counters.\nThese counters provide a good overall look at how much data is crossing the\nmemory bus over the course of a single frame. Do your best to minimize the\namount of data that you send over the bus, since memory bandwidth is a large\nsource of battery drain on mobile devices.\n**Figure 2.**Read + Write Total Counters\n\nYou can also examine the **Vertex Memory Read (Bytes/Second)** and **Texture Memory Read (Bytes/Second)**\ncounters to determine the portion of the bandwidth used for vertex and texture\ndata.\n**Figure 3.**Vertex + Texture Memory Read Counters\n\nWhat you consider \"good\" for these values depends on the type of workloads\nseen in your app. For instance, 2D applications may see relatively large\n(\\~2+GB/s) amounts of texture memory read bandwidth being used, but the vertex\nmemory bandwidth may be very minimal (\\~50MB/s). For more details, take a look at\nthe documentation for [Analyze vertex memory bandwidth](/agi/sys-trace/vertex-memory-bw) and\n[Analyze texture memory bandwidth usage](/agi/sys-trace/texture-memory-bw).\n\n### Fetch stalls\n\nLook at the **% Vertex Fetch Stall** , **% Texture Fetch Stall** , and **% Stall on System Memory** counters since these will give you some hints to the overall memory performance of our application. If the values are higher than roughly 5%, this suggests that\nyour app is either not laying out data in memory in an efficient way or is\naccessing its data in an efficient way to take advantage of the cache.\nTake a look at the [Analyze vertex memory bandwidth](/agi/sys-trace/vertex-memory-bw) and\n[Analyze texture memory bandwidth usage](/agi/sys-trace/texture-memory-bw) for details on\nimproving memory usage for these types of assets.\n**Figure 4.**Memory Stall Counters\n\nMali devices\n------------\n\nOn Mali devices, start by first highlighting a period of time consistent with a single GPU frame as described in [Estimate CPU and GPU frame processing times](/agi/sys-trace/long).\nUse the technique described on that page involving the usage of the **GPU % Utilization**\nor similar counter track for your frame time boundaries as the counter tracks all use the same timing technique and will allow for more accurate estimates of memory utilization (compared to using the frame time boundaries derived from the GPU slices whose data is collected independently from the counter track data).\n**Figure 5.**Utilization track lining up with the counters you are interested in below it\n\n### Output External Totals\n\nAfter you've highlighted a single frame in the **System Profiler** , start by\nlooking at the **Output External Read bytes** **Output External Write bytes**\ncounters. These counters provide a good overall look at how much data is crossing the memory bus over the course of a single frame. Do your best to minimize the amount of\ndata you send over the bus, since memory bandwidth is a large source of battery\ndrain on mobile devices.\n**Figure 6.**Output External counter tracks\n\n### Input internal totals\n\nThere are also counters that provide you with information about the caches themselves. The counters you are interested in are \"Input internal \\[read\\|write\\] stall cycles\". Higher values for these mean that you are hitting the cache successfully but there are too many read requests being made and as a result shader code is stalling waiting to get access to memory.\n**Figure 7.**Input Internal counter tracks\n\n### Fetch stalls\n\nThe next set of counters you can look at are the **Vertex Prefetcher Stall Cycles** and the **Texture Fetch Stall** counters as these will give you some hints to the overall memory performance of our application. If you are seeing values higher than \\~5% this implies that you are either not laying out our data in memory in an efficient way or accessing our data in an efficient way to take advantage of the cache. Take a look at the Analyzing \\[Vertex\\|Texture\\] Memory Bandwidth articles for details on how to improve the memory usage for these types of assets\n**Figure 8.**Fetch Stalls counter tracks"]]
