מאפייני השימוש בזיכרון של אפליקציה הם היבט בסיסי בביצועים שלה. אפשר להשתמש בSystem Profiler כדי לנתח את המאפיינים האלה על ידי עיון במידע הזמין של מונה ה-GPU.
מכשירי Adreno
במכשירי Adreno, מתחילים בסימון תקופת זמן שתואמת לפריים יחיד של GPU, כפי שמתואר במאמר הערכת זמני העיבוד של פריים במעבד ובמעבד הגרפי. כדי להעריך את השימוש בזיכרון בצורה מדויקת יותר (בהשוואה לשימוש בגבולות של זמן הפריים שנגזרים מהפרוסות של ה-GPU, שהנתונים שלהן נאספים בנפרד מהנתונים של מונה המעקב), כדאי להשתמש בטכניקה שמתוארת בדף הזה, שכוללת שימוש בGPU % Utilization או במעקב אחר מונה דומה לגבולות של זמן הפריים. הסיבה לכך היא שכל המונים משתמשים באותה טכניקת תזמון.
קריאה/כתיבה של סה"כ
אחרי שמסמנים פריים יחיד בכלי ליצירת פרופילים, מתחילים בבדיקה של מוני Read Total (Bytes/sec) ו-Write Total (Bytes/sec). המונים האלה מספקים תמונה כללית טובה של כמות הנתונים שעוברים באפיק הזיכרון במהלך פריים יחיד. כדאי לצמצם ככל האפשר את כמות הנתונים שאתם שולחים דרך האפיק, כי רוחב פס של הזיכרון הוא מקור משמעותי לניקוז הסוללה במכשירים ניידים.
אפשר גם לבדוק את מוני הנתונים Vertex Memory Read (Bytes/Second) ו-Texture Memory Read (Bytes/Second) כדי לדעת איזה חלק מרוחב הפס משמש לנתוני קודקודים וטקסטורות.
מה שאתם מחשיבים כ'טוב' לגבי הערכים האלה תלוי בסוגי עומסי העבודה שמוצגים באפליקציה. לדוגמה, באפליקציות דו-ממדיות יכול להיות שימוש ברוחב פס גדול יחסית של זיכרון טקסטורה לקריאה (~2GB/s ומעלה), אבל רוחב הפס של זיכרון הקודקודים עשוי להיות מינימלי (~50MB/s). פרטים נוספים זמינים במסמכי התיעוד בנושא ניתוח רוחב פס של זיכרון קודקודים וניתוח השימוש ברוחב פס של זיכרון טקסטורה.
אחזור דוכנים
כדאי לעיין במונים % Vertex Fetch Stall, % Texture Fetch Stall ו-% Stall on System Memory, כי הם יספקו לכם רמזים לגבי ביצועי הזיכרון הכוללים של האפליקציה. אם הערכים גבוהים מ-5% בערך, יכול להיות שהאפליקציה לא מסדרת את הנתונים בזיכרון בצורה יעילה, או שהיא ניגשת לנתונים בצורה יעילה כדי לנצל את היתרונות של המטמון. במאמרים ניתוח רוחב הפס של הזיכרון של קודקסי הצללה וניתוח השימוש ברוחב הפס של הזיכרון של הטקסטורות מוסבר איך לשפר את השימוש בזיכרון עבור סוגי הנכסים האלה.
מכשירי מאלי
במכשירי Mali, מתחילים בסימון של פרק זמן שתואם לפריים יחיד של GPU, כפי שמתואר במאמר הערכת זמני העיבוד של פריים ב-CPU וב-GPU. כדי להעריך את השימוש בזיכרון בצורה מדויקת יותר (בהשוואה לשימוש בגבולות של זמן הפריים שנגזרים מהפרוסות של ה-GPU, שהנתונים שלהן נאספים בנפרד מהנתונים של מונה המעקב), כדאי להשתמש בטכניקה שמתוארת בדף הזה, שכוללת שימוש בGPU % Utilization או במעקב אחר מונה דומה לגבולות של זמן הפריים. הסיבה לכך היא שכל המונים משתמשים באותה טכניקת תזמון.
פלט של סה"כ חיצוני
אחרי שמסמנים פריים יחיד בSystem Profiler, מתחילים בבדיקת מוני Output External Read bytes (בייטים של קריאה חיצונית בפלט) ו-Output External Write bytes (בייטים של כתיבה חיצונית בפלט). המונים האלה מספקים תמונה כללית טובה של כמות הנתונים שעוברים באפיק הזיכרון במהלך פריים אחד. כדאי לצמצם ככל האפשר את כמות הנתונים שאתם שולחים דרך האפיק, כי רוחב פס הזיכרון הוא מקור משמעותי לניצול הסוללה במכשירים ניידים.
הזנת סכומים פנימיים
יש גם מוניטורים שמספקים מידע על מטמונים. המדדים שמעניינים אותך הם 'Input internal [read|write] stall cycles'. ערכים גבוהים יותר במדדים האלה מצביעים על כך שהגישה למטמון הצליחה, אבל יש יותר מדי בקשות קריאה, וכתוצאה מכך קוד ההצללה מושהה בהמתנה לגישה לזיכרון.
אחזור דוכנים
המדדים הבאים שמומלץ לבדוק הם Vertex Prefetcher Stall Cycles ו-Texture Fetch Stall, כי הם יתנו לכם רמזים לגבי ביצועי הזיכרון הכוללים של האפליקציה. אם אתם רואים ערכים גבוהים מ-5%, זה אומר שאתם לא מסדרים את הנתונים שלנו בזיכרון בצורה יעילה או שאתם לא ניגשים לנתונים שלנו בצורה יעילה כדי לנצל את היתרונות של המטמון. כדי לקבל פרטים על שיפור השימוש בזיכרון עבור סוגי הנכסים האלה, אפשר לעיין במאמרים בנושא ניתוח רוחב הפס של הזיכרון [Vertex|Texture].
