ביצועים חשובים לנו בכל מוצר, כולם יודעים שלא ניתן לשחרר מוצר אם הביצועים אינם טובים, כלומר אם הביצועים אינם עומדים בציפיות של הלקוח. כאשר מתכננים מוצר כבר מהיום הראשון עלינו לחשוב על ביצועים. עלינו לחשוב על ביצועים לא כעל בעיה שנתגלתה אלה כעוד יכולת של המוצר.
תהליכים
כאשר אנו נגשים לתכנן מוצר יש צורך לחשוב במושגים של תהליכים, תהליכים מאפשרים לנו להתמקד במה שבאמת חשוב לנו במוצר. תהליכים נגזרים מהלקוחות ומהמתחרים של המוצר, יש ללמוד את הלקוח, ללמוד את הצרכים ולאבחן מה דרוש ללקוח, יש לבחון מה גורם ללקוח התלהבות מהמוצר. דברו עם הלקוחות וגלו מה הלקוח מצפה מבחינת ביצועים מהמוצר. בנוסף ללקוח יש ללמוד את המתחרים, מה גורם למתחרים להיות יותר טובים מכם מבחינת ביצועים.
בהכנת רשימת התהליכים יש לערוך רשימה של תהליכים מרכזיים, יש לעבור על הרשימה ולסנן אותה, על הרשימה להיות קצרה וברורה, שימו לב שלא ליצור רשימה ארוכה של תהליכים, רשימה קצרה וברורה תאפשר לכם לכוון לשיפור ביצועים ממוקד ובכך לכוון את המוצר ליעד הרצוי.
דוגמאו לתהליכים מרכזיים:
זמן איתחול האפליקציה, זמן תגובה למשתמש, זמן אחזור שאילתה, קצב עדכון מסך בזמן הופעת אנימציה
יעדים
קבעו יעדים, יש לחשוב מכווני יעדים, בכדי להחליט אם האפליקציה רצה מהר או לאט יש להציב יעדים למדידה כנגד. היעדים אמורים לשקף את ציפיות הלקוח, לעיתים קשה לחשוב על מספרים ספציפיים תוך כדי תהליך הפיתוח, זה בסדר, קבעו יעדים מספריים אפילו זמניים תוך כדי תהליך הפיתוח, עדיף שיהיו יעדים מספריים כלשהם מאשר כלום, ניתן לשנות יעדים אלו באיטרציות עתידיות של תהליך הפיתוח. ככלל לכל תהליך מרכזי דרוש שיהיו לכם יעדים מספריים.
דוגמאות ליעדים מספריים:
דרוש שזמן איתחול אפליקציה יהיה לא יותר מ-100 מילי שניות או קצב רענון התמונה בזמן אנימציה יהיה לפחות 50 תמונות בשניה.
תשתית
הכירו את התשתית עליה רצה האפליקציה, לפני שאתם מתחילים לקודד עליכם להכיר את התשתית עליה תרוץ האפליקציה, אסור שתהינה לכם הפתעות בשלבי הפיתוח האחרונים, ככל שאנו מתקרבים לתאריך השחרור של האפליקציה יותר קשה לשפר ביצועים, בשלבי הפיתוח האחרונים שיפור הביצועי הופך לתיקון באג ולא לעוד יכולת כמו שרצינו למכתחילה ולא קל לתקן באג שכזה היות ולרוב יש לערוך שינויים דראסטיים באפליקציה.
הפוך את תהליך שיפור הביצועים לתהליך איטראטיבי.
ככלל התהליך אמור לכלול את השלבים הבאים: מדידה, בחינה – בדיקת התוצאות, שיפור ותיקון וזהו תהליך איטרטיבי תוך כדי תהליך התיקון.
מתחילת תהליך התיקון ועד לסופו עליך למדוד את ביצועי האפליקציה בסביבה אמינה ויציבה בכדי למנוע השפעות סביבתיות על ביצועי האפליקציה. הננו רוצים להמנע מקבלת מספרים צפויים או בלתי צפויים בתור תוצאות אשר מושפעים מהשפעות סביבתיות.
דוגמא: יש לבטל Wireless במכונה או עידכונים אוטומטיים כמו SMS העלולים לחבל בתוצאות בדיקת הביצועים.
ברגע שמדדת את ביצועי האפליקציה עליך לזהות את השינויים אשר יש לבצע באפליקציה ואשר יחוללו את שיפור הביצועים המקסימלי
שיפור ביצועים אינו דומה לתיקון באגים, עליך לבנות אותו לתוך המוצר עליך להתחיל מהיום הראשון של פיתוח האפליקציה.
שיפור ביצועי אפליקציית WPF
נתחיל באיך WPF מצייר על המסך ?
WPF ינסה להשתמש ב-Graphic Processing Unit – GPU לשם השגת Hardware Rendering ואם לא יצלח יהיה שימוש ב-Software Rendering.
WPF מצייר על המסך בשימוש בשני ערוצים, , Hardware Pipeline ו-Software Pipeline
Hardware Rendering
Hardware Rendering משתמש ב-Microsoft Direct3D וזמין לשימוש בכרטיסים התומכים ב-DirectX 7 ומעלה. קיימת אופטימיזציה נוספת לכרטיסים התומכים DirectX 9 ו-Picture Series 2.0+
Software Rendering משתמש ב-CPU והמעבר מ-Software ל-Hardware הינו מעבר חלק בתוך תשתית WPF
עקב תכונה זו של מעבר חלק מאוד קשה למפתח לפתח אפליקציה למכונה מסויימת לכן ישנם API שונים המאפשרים לשאול את התשתית על איזה סוג חומרה האפליקציה רצה.
לדוגמא: System.Windows.Media.RenderCapability.Tier מאפשר לנו לדעת את יכולות החומרה עליהם אנו רצים.
סוג החומרה מקוטלג לשלש קטגוריות שונות:
Tier 0 – כרטיסי מסך בעלי יכולת נמוכה
Tier 1 – כרטיסי מסך בעלי יכולת סבירה
Tier 2 – כרטיסי מסך בעלי יכולת גבוהה
מידע זה יאפשר לנו לדעת האם ה-GPU בשימוש, אם כן ניתן יהיה באמצעותו לשפר את ביצועי האפליקציה. אם נדע מה מואץ על ידי החומרה ומה לא נוכל לנצל יותר טוב את ה-GPU.
לשימוש ב-API זה יש לקרא את הביטים העליונים קרי ע"י שימוש ב:
16 << System.Windows.Media.RenderCapability.Tier
Tier 0
שום פעילות אינה מואצת ע"י שימוש בחומרה.
רמת החומרה זו הינה רמת חומרה נמוכה מאוד כך שלא ניתן לנצל את החומרה כלל.
Tier 1
תחת קטגוריה זו כמעט כל כתיבות המסך בשימוש ב-2D יואצו ו-3D Rasterization יואץ.
הפעולות אשר לא יואצו ויש להימנה מהן בסוג חומרה זה:
Opacity Mask
Bitmap Effects
Printed Content
תוכן אשר משתמש מרונדר ל-RenderTargetBitmap
תוכן אשר משתמש ב-Tilebrush כאשר Timemode=Tile (כל שאר המודים ירונדרו ב-Hardware) – למה כי יש צורך ליצור Template עבור ב-Tile של ה-Brush ולספק זאת ל-GPU
משטחים אשר דורשים כמות זיכרון גדולה מכמות הזכרון המצוייה בכרטיס המסך ל-Texute – Texture Size
כל פעילות הדורשת זיכרון מעבר לגבולות הזכרון של כרטיס המסך.
Layered Windows
חישובי 3D Lighting
Color-Keyed Alpha
חלק מ-Text Rendering – sub-pixel font rendering יבוצע ב-shaders אם קיים - לא כל הכרטיסים ב-Tier 1 תומכים ב-shaders אם כן יהיה ניצול של תכונה זו.
Tier 2
תחת קטגוריה זו כל החומרות העדכניות בתעשיה וחזקות ביסודן ויש שימוש בתכונות הכרטיסים.
הפעולות אשר יואצו בקטגוריה זו אך לא בקטגוריות קודמות:
Radial Gradients
חישובי 3D Lighting
Text Rendering
3D Antialiasing – זמין רק בכרטיסים של קטגוריה זו ורק כאשר רצים מעל Vista
כל הפעולות אשר לא יואצו כלומר שתמיד יהיה בהן שימוש בתוכנה קרי CPU, במילים אחרות להלן הפעולות אשר יפגעו בביצועים אם יהיה שימוש בהן ולכן יש צורך לחשוב טוב טוב אם אנו באמת זקוקים להן:
Opacity Masks
Bitmap Effects
Printed Content
תוכן אשר משתמש מרונדר ל-RenderTargetBitmap
תוכן אשר משתמש ב-Tilebrush כאשר Timemode=Tile
משטחים אשר דורשים כמות זיכרון גדולה מכמות הזכרון המצוייה בכרטיס המסך ל-Texute – Texture Size
כל פעילות הדורשת זיכרון מעבר לגבולות הזכרון של כרטיס המסך.
Layered Windows
תאימות כרטיסי מסך
Tier 0
כרטיסי מסך התואמים DirectX קטן מ-7
Tier 1
כרטיסי מסך התואמים DirectX בין 7 ל-9 לא כולל, כוללים 32MB זיכרון ומעלה ותומכים ב-Pixel Shader מ-1 ומעלה ו-Vertex Shader מ-1 ומעלה
Tier 2
כרטיסי מסך התואמים DirectX גדול מ-9 ומעלה כוללים 128MB זיכרון ומעלה ותומכים ב-Pixel Shader מ-2 ומעלה, Vertex Shader מ-1 ומעלה ו-Multitexture Units מ-4 ומעלה.
לדוגמא:
Tier 0
Intel GMA900 GMA950
Tier 1
ATI Radeon 256, 7000,7500,8500,9000,9100,9200,9250
Nvidia Geforce 256,Gefore2 mx100,mx200,mx,mx400,gts,pro,ti,ultra,Geforce 3 ti200,ti500
Geforce4 mx420,mx440,mx460,mx4000,ti4200,ti4400,ti4600,ti4800
Tier 2
Nvidia Geforce FX-series, 6xxx series,7xxx series,8xxx series
ATI Radeon 9550,9600,9800,X-series
לסיכום:
אם ידוע על איזו תשתית אמורה לרוץ האפליקציה ניתן לתכנן ולכון לכך מראש, אם לא ידוע ניתן להשתמש ב-API בכדי לכבות יכולות של האפליקציה ולהתאימה למחשב היעד לדוגמא אם ידוע שאנו רצים ב-HighEnd ניתן להפעיל אנימציות ותלת מימד אבל אם האפליקציה רצה עםם כרטיסים נחותים ניתן לכבות יכולות אלו באפליקציה ולגרום לאפליקציה לרוץ על דו מימד במקום.
WPF הינה תשתית עשירה מאוד ניתן לכתוב אפליקציות עשירות במאמץ מועט כך שחשוב מאוד לדעת מה יכולות התשתית כמה זה עולה ואיך לבצע זאת.
ככלל הכיוון בו אנו אמורים לפתח הינו ממהירות לעושר אפליקטיבי, אנו אמורים לפתח אפליקציה למהירות מקסימלית בשימוש ביכולות מינימאליות ובאמצעים הפשוטים ביותר בכדי לענות על דרישות האפליקציה ואז לעבור להוספת יכולות מתקדמות כך נדע מה המינימום של זמני הביצוע, מה הקו התחתון מבחינת הביצועים לתהליך הנידון. ככל שנוסיף יכולות נשווה את ביצועי האפליקציה ליעדים אותם קבענו ונוכל למנוע הכנסת יכולות אשר יפגעו בביצועי האפליקציה.
בחלק הבא של מאמר זה אעבור על רכיבים שונים ותחליפיהם ה-"זולים" יותר לשימוש מבחינת ביצועים.