이 글은 아래 원문을 번역한 글로 의역이 있을 수 있습니다. 정확한 의미를 파악하고 싶으신 분은 원문을 참고해주시기 바랍니다.
원문: https://developer.chrome.com/blog/memory-inspector/
저작권 정보: https://developers.google.com/terms/site-policies
이 글에서는 Chrome 91에 출시된 메모리 검사기를 소개합니다. 메모리 검사기를 통해 ArrayBuffer, TypedArray, DataView 및 Wasm Memory를 검사할 수 있습니다.
소개
Array Buffer의 데이터를 이해하고 싶었던 적이 있습니까?
Memory Inspector 이전에는 DevTools로 Array Buffer에 대한 제한된 정보만을 얻을 수 있었습니다. 디버깅 세션 동안 Scope 뷰에서 검사하는 것은 Array Buffer내의 단일 값 목록을 보는 것으로 제한되었기 때문에 데이터를 전체적으로 이해하기가 어려웠습니다. 예를 들어, Scope 뷰는 아래에서 버퍼를 확장 가능한 어레이 범위로 표시합니다.
버퍼 내의 특정 범위로 이동하는 것은 어려웠으며, 사용자가 최종적으로 해당 인덱스로 이동하려면 아래로 스크롤해야 했습니다. 그러나 어떤 위치로 이동하는 것은 쉬울 지라도 실제로 값을 조사하는 방법은 번거로워서 이 숫자들이 무엇을 의미하는지 구별하기가 어려웠습니다.
Memory Inspector 를 사용한 값 검사
Chrome 91에서는 Array Buffer를 검사하는 도구인 Memory Inspector를 소개합니다. 이전에는 메모리 검사 도구를 통해 이진 데이터를 확인했을 수 있습니다. 이 도구는 주소와 함께 그리드의 이진 컨텐츠를 표시하며 기본 값을 해석하는 다양한 방법을 제공합니다.. 이제 Memory Inspector(메모리 검사기)를 사용하여 내용을 보고 탐색하며 값을 해석하는 데 사용할 유형을 선택할 수 있습니다. 바이트 바로 옆에 ASCII 값이 표시되며 사용자가 다른 엔디안(컴퓨터의 메모리와 같은 1차원의 공간에 여러 개의 연속된 대상을 배열하는 방법)을 선택할 수 있습니다. 아래의 메모리 검사기를 참조하십시오.
Memory Inspector 설계
이 파트에서는 Web Components를 사용하여 Memory Inspector를 설계하는 방법과 설계 목표 중 하나와 구현 방법을 살펴보겠습니다. 자세한 내용을 보려면 Memory Inspector 설계 문서를 참조하십시오.
Jack이 Web Components를 사용하여 UI 구성 요소를 빌드하는 방법에 대한 내부 가이드를 게시한 웹 구성 요소로 마이그레이션에 대한 블로그 게시물을 보셨을 것입니다. Web Components로의 마이그레이션은 Memory Inspector에 대한 작업과 동시에 이루어졌고, 그 결과 우리는 새로운 시스템을 시도하기로 결정했습니다. 아래 다이어그램은 메모리 검사기를 만들기 위해 만든 구성 요소를 나타냅니다(내부적으로 선형 메모리 검사기라고 함).
LinearMemoryInspector구성 요소는 Memory Inspector의 모든 요소를 구성하는 하위 구성 요소를 결합한 상위 구성 요소입니다. 기본적으로 Uint8Array와 address를 사용하며, 변경 시마다 하위 항목으로 데이터를 전파하여 렌더링을 트리거합니다. LinearMemoryInspector 스스로 세 가지 하위 구성 요소를 렌더링합니다.
- LinearMemoryViewer(값 표시),
- LinearMemoryNavigator(내비게이션 허용)
- LinearMemoryValueInterpreter(기본 데이터에 대한 다양한 유형 해석 표시).
후자는 그 자체가 상위 구성 요소이며, .ValueInterpreterDisplay(값 표시) 및 ValueInterpreterSettings(디스플레이에서 볼 유형 선택)를 렌더링 합니다.
각 컴포넌트는 UI의 작은 구성 요소 하나만 나타내도록 설계되었으므로 필요한 경우 컴포넌트를 재사용할 수 있습니다. 컴포넌트에 새 데이터가 설정될 때마다 다시 렌더링이 트리거되어 컴포넌트에 설정된 데이터에 반영되는 변경 사항을 표시합니다. 컴포넌트가 포함된 워크플로우의 한 예가 아래에 나와 있습니다. 사용자가 주소 표시줄에서 주소를 변경하는 경우 새 데이터를 설정하여 업데이트를 트리거합니다. 이 경우 볼 주소가 다음과 같습니다.
LinearMemoryInspector는 LinearMemoryNavigator에서 리스너로 추가됩니다. addressChanged 기능은 address-changed 이벤트에서 트리거됩니다. 사용자가 주소 입력을 편집하는 즉시 앞서 언급한 이벤트를 전송하여 address-changed 함수를 호출합니다. 이 기능은 이제 주소를 내부적으로 저장하고 data(address, ..) setter를 사용하여 하위 구성요소를 업데이트합니다. 하위 구성요소는 내부적으로 주소를 저장하고 보기를 다시 렌더링하여 해당 주소의 내용을 표시합니다.
설계 목표: 버퍼 크기에 관계없이 성능 및 메모리 사용률 향상
메모리 검사기를 설계하는 동안 염두에 둔 한 가지 측면은 메모리 검사기의 성능이 버퍼 크기와 무관해야 한다는 것이었습니다.
이전 파트에서 보셨듯이, LinearMemoryInspector 컴포넌트는 값을 렌더링하기 위해 UInt8Array를 사용합니다. 또한 메모리 검사기가 전체 데이터의 일부만 표시하므로 메모리 검사기가 전체 데이터를 보관할 필요가 없는지 확인하고 싶었습니다. (예: Wasm 메모리는 4GB까지 클 수 있으며 메모리 검사기 내에 4GB를 저장하기를 원하지 않음).
따라서 Memory Inspector의 속도와 메모리 소비량이 표시된 실제 버퍼와 별개인지 확인하기 위해 LinearMemoryInspector는 원래 버퍼의 하위 범위만 유지합니다.
이렇게 하려면 먼저 LinearMemoryInspector는 memoryOffset과 outerMemoryLength의 두 가지 argudments가 필요합니다.. memoryOffset은 전달된 Uint8 어레이가 시작되고 올바른 데이터 주소를 렌더링하는 데 필요한 오프셋을 나타냅니다. outerMemoryLength는 원래 버퍼의 길이이며 표시할 수 있는 범위를 파악하는 데 필요합니다.
이 정보를 통해 실제로 모든 데이터를 배치하지 않고도 이전과 동일한 view(address주변의 내용)를 렌더링할 수 있습니다. 그러면 다른 범위에 해당하는 다른 주소가 요청될 경우 어떻게 해야 할까요? 이 경우 LinearMemoryInspector는 유지되는 현재 범위를 업데이트하는 RequestMemoryEvent를 트리거합니다. 예는 다음과 같습니다.
이 예에서 사용자는 메모리 페이지를 탐색하며(메모리 검사기가 데이터 청크를 표시하는 페이징을 사용함), 이 페이지는 PageNavigationEvent를 트리거하며, 이 이벤트 자체가RequestMemoryEvent를 트리거합니다. 이 이벤트는 새 범위 가져오기를 시작하여 LinearMemoryInspector로 전파됩니다.데이터 설정을 통해 구성 요소를 검사합니다. 따라서 새로 가져온 데이터를 보여 줍니다.
오, 그리고 당신은 알고 있었나요? WASM 및 C/C++ 코드 메모리를 검사할 수도 있습니다.
메모리 검사기는 JavaScript의 ArrayBuffers에 사용할 수 있을 뿐만 아니라 C/C++ 참조/포인트로 가리킨 Wasm 메모리와 메모리를 검사하는 데도 사용할 수 있습니다.(DWARF-extension 사용). 아직 검사하지 않았다면 시도해 보십시오!(최신 도구로 웹 어셈블리 디버깅). 웹에서 C++의 네이티브 디버깅을 위해 동작 중인 메모리 검사기에 대한 outlook:
결론
이 글은 메모리 검사기를 제시하고 그 설계를 보여주었다. Memory Inspector가 ArrayBuffer에서 무슨 일이 일어나고 있는지 이해하는 데 도움이 되기를 바랍니다. 개선할 사항이 있으면 알려주시고 버그를 제출하십시오!
Portions of this page are reproduced from work created and shared by Google and used according to terms described in the Creative Commons 4.0 Attribution License.
이 페이지의 일부는 Google이 만들고 공유한 작업에서 복제하여 Creative Commons 4.0 Attribution License에 설명된 조건에 따라 사용합니다.
'성능' 카테고리의 다른 글
| Towards an animation smoothness metric (한글) (2) | 2022.09.21 |
|---|---|
| The Complete Guide to Lazy Loading Images - 1 (한글) (0) | 2022.05.18 |
| Demistifying webpack's 'import' function: using dynamic arguments (한글) (1) | 2022.02.23 |
| Tree-Shaking: A Reference Guide (한글) (0) | 2021.07.28 |
| Trash talk: the Orinoco garbage collector(한글) (0) | 2021.07.14 |
