앱의 메모리 사용 특성은 앱 성능의 기본적인 측면입니다. 시스템 프로파일러를 사용하면 사용 가능한 GPU 카운터 정보를 보고 이러한 특성을 분석할 수 있습니다.
Adreno 기기
Adreno 기기에서는 먼저 CPU 및 GPU 프레임 처리 시간 예상에 설명된 대로 단일 GPU 프레임과 일치하는 기간을 강조표시합니다.
카운터 추적은 모두 동일한 타이밍 기법을 사용하며 (카운터 트랙 데이터와는 별개로 데이터가 수집되는 GPU 슬라이스에서 파생된 프레임 시간 경계를 사용하는 것에 비해) 메모리 사용률을 더 정확하게 예측할 수 있으므로 프레임 시간 경계에 GPU 비율 사용률 또는 이와 유사한 카운터 트랙의 사용과 관련된 이 페이지에 설명된 기법을 사용하세요.
그림 1. 사용률 추적이 그 아래의 관련 카운터와 정렬됨
읽기/쓰기 총계
프로파일러에서 단일 프레임을 강조표시했으면 먼저 읽기 합계 (바이트/초) 및 쓰기 총계 (바이트/초) 카운터를 살펴보세요.
이러한 카운터는 단일 프레임 과정에서 메모리 버스를 통과하는 데이터의 양을 전반적으로 잘 보여줍니다. 메모리 대역폭은 휴대기기에서 배터리 소모의 큰 원인이므로 버스를 통해 보내는 데이터의 양을 최소화하세요.
그림 2. 읽기 + 쓰기 총 카운터
Vertex 메모리 읽기 (바이트/초) 및 텍스처 메모리 읽기 (바이트/초) 카운터를 검사하여 버텍스 및 텍스처 데이터에 사용되는 대역폭 부분을 확인할 수도 있습니다.
그림 3. Vertex + 텍스처 메모리 읽기 카운터
이러한 값에 대해 '양호'한 것은 앱에 표시되는 워크로드 유형에 따라 다릅니다. 예를 들어 2D 애플리케이션에서는 비교적 큰(약 2GB/초)의 텍스처 메모리 읽기 대역폭이 사용될 수 있지만, 버텍스 메모리 대역폭은 매우 미미할 수 있습니다 (~50MB/s). 자세한 내용은 버텍스 메모리 대역폭 분석 및 텍스처 메모리 대역폭 사용량 분석 문서를 참고하세요.
가져오기 스톨
버텍스 가져오기 중단 비율(%), 텍스처 가져오기 중단 비율(%), 시스템 메모리에서 중단 비율(%) 카운터를 살펴보세요. 애플리케이션의 전반적인 메모리 성능에 대한 몇 가지 힌트를 제공합니다. 값이 약 5%보다 크면 앱이 메모리에 데이터를 효율적인 방식으로 배치하지 않았거나 캐시를 활용하기 위해 효율적인 방식으로 데이터에 액세스하고 있음을 나타냅니다.
이러한 유형의 애셋의 메모리 사용량을 개선하는 방법에 관한 자세한 내용은 버텍스 메모리 대역폭 분석 및 텍스처 메모리 대역폭 사용량 분석을 참고하세요.
그림 4. 메모리 스톨 카운터
말리 기기
말리 기기에서는 먼저 CPU 및 GPU 프레임 처리 시간 추정에 설명된 대로 단일 GPU 프레임과 일치하는 기간을 강조 표시합니다.
카운터 추적은 모두 동일한 타이밍 기법을 사용하며 (카운터 트랙 데이터와는 별개로 데이터가 수집되는 GPU 슬라이스에서 파생된 프레임 시간 경계를 사용하는 것에 비해) 메모리 사용률을 더 정확하게 예측할 수 있으므로 프레임 시간 경계에 GPU 비율 사용률 또는 이와 유사한 카운터 트랙의 사용과 관련된 이 페이지에 설명된 기법을 사용하세요.
그림 5. 사용률 추적이 관심 있는 카운터와 정렬되어 있음
출력 외부 총계
시스템 프로파일러에서 단일 프레임을 강조표시한 후에는 먼저 Output External Read bytes(출력 외부 읽기 바이트)Output External Write bytes(출력 외부 쓰기 바이트) 카운터를 살펴봅니다. 이러한 카운터는 단일 프레임 과정에서 메모리 버스를 통과하는 데이터의 양을 전반적으로 잘 보여줍니다. 메모리 대역폭은 휴대기기의 배터리 소모에 큰 영향을 미치므로 버스를 통해 전송하는 데이터의 양을 최소화하세요.
그림 6. 출력 외부 카운터 트랙
내부 총계 입력
캐시 자체에 대한 정보를 제공하는 카운터도 있습니다. 관심이 있는 카운터는 '내부 [읽기|쓰기] 스톨 주기 입력'입니다. 값이 클수록 캐시에 성공적으로 도달하고 있지만 읽기 요청이 너무 많아서 셰이더 코드가 메모리에 액세스하기 위해 대기하고 있음을 의미합니다.
그림 7. 내부 카운터 트랙 입력
가져오기 스톨
다음으로 살펴볼 수 있는 카운터 세트는 Vertex Prefetcher Stall Cycles 및 Texture Fetch Stall 카운터입니다. 애플리케이션의 전반적인 메모리 성능에 관한 힌트를 제공하기 때문입니다. 5% 보다 큰 값이 표시된다면 데이터를 효율적인 방식으로 메모리에 배치하지 않았거나 캐시를 활용할 수 있는 효율적인 방식으로 데이터에 액세스하고 있음을 의미합니다. 이러한 유형의 애셋의 메모리 사용량을 개선하는 방법에 대한 자세한 내용은 [Vertex|Texture] 메모리 대역폭 분석 문서를 참고하세요.
그림 8. 가져오기 중단 카운터 트랙
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","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"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],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"]]
