מכירים אתרים איטיים?
תוכנות שבקושי זזות?
או יותר גרוע - אנימציות טעינה תקועות -
זה לרוב קורה בגלל קוד לא יעיל או תהליכים ארוכים!
יש כמה דרכים לדעת שאתם צריכים לבנות אסטרטגיית ייעול:
יש פה משהו נסתר - מתי אתם צריכים לייעל את הקוד?
כשאתם שמים לב!
כל עוד התוכנה עובדת מהר מספיק ואף אחד לא מתלונן - האם אתם צריכים לייעל?
בשביל לכתוב קוד יעיל לרוב הקוד יהיה משוכתב מקוד קיים או מראש מעוצב על מנת שייעבוד יותר מהר.
ההגדרה הזו מגדירה מאפיין לקוד אשר נקרא “ביצועים”.
לפי סדר עדיפויות ניתן לגרוע ממאפיינים אחרים כגון - קריאות, יכולת תחזוקה, קוד וכדו…
לעיתים גם נעזוב קונספטים בסיסיים כמו לוגים ואודיט או מונחה עצמים.
במקרים קיצוניים - נשכתב את הקוד בשפות תוכנה נמוכות כמו שפת C או אסמבלי.
מדידה היא הדבר הראשון שאתם צריכים לעשות.
אי אפשר לשפר את הקוד נטו ע”פ הרגשה - כדי לשפר צריך לדעת כמה זמן זה לוקח.
בשביל לדעת כמה זמן - צריך למדוד!
אז איך אנחנו מודדים?
הדרך הראשונה זה להשתמש בתוכנה שלנו כקופסה שחורה - ניקח את המערכת כמו שהיא ונמדוד כמה זמן לוקח לנו לעשות את התהליכים.
כמה זמן לקח כאשר לחצתם על כפתור ועד שעברתם עמוד?
כמה זמן לקח לשלוח תגובה?
אתם מוזמנים לנסות את זה באתרים ואפליקציות שאתם מכירים!
בעזרת אילו כלים נמדוד כאן?
נמדוד בכלים שהם ב-High level
כגון:
בשיטת הקופסה הלבנה אנו נכנסים לתוך המערכת ומתחילים למדוד תהליכים פנימיים.
ברמה של סרביסים, תוכנות ואף פונקציות!
יש מגוון כלים למדידה כאן.
https://developer.chrome.com/docs/devtools/performance/reference
https://learn.microsoft.com/en-us/visualstudio/profiling/hot-path-to-root?view=vs-2022
https://github.com/dotnet/BenchmarkDotNet
https://blog.logrocket.com/benchmarking-golang-improve-function-performance/
לעיתים זה לא משנה באיזו רמה אנחנו נבצע מדידה ואיך נסתכל על זה - לפעמים המערכת שלנו היא פשוט איטית כי היא לא עוצבה מלכתחילה להכיל את הביצועים ההכרחיים.
הסיבה לכך יכולה להיות מגוונת:
כך או כך אתם תמצאו את עצמכם משכתבים את המערכת ומעצבים אותה מחדש.
הצעד האחרון במערכת אשר בנויה היטב, הפונקציות כתובות טוב ונדמה לנו שהלימון האחרון נסחט כבר יש לנו עוד כמה טריקים בשרוול.
כל מהנדס ביצועים בתחום התוכנה יודע שהביצועים הכי גבוהים מגיעים בשילוב התוכנה עם החומרה!
זה כולל:
באחת המשימות הגדולות שלי התבקשתי לכתוב ספרייה לסרלוז פורמט עבור מיגרציה של נתונים.
אז כתבתי את הקוד, וכתבתי שכבות גדולות שם, ואפילו התבקשתי לצלול לעומק קוד שלא אני כתבתי - למעשה כתבו אותו אי שם בארה”ב והודו.
בכל מקרה - הקוד היה צריך להקצות מקום באיטרציות עבור צ’אנקים של מידע.
וזו בעיה קלאסית של הקצאה באיטרציות.
נניח ויש לכם זיכרון רציף אשר אתם כל פעם מקצים אותו מחדש לפי הגודל:
זה יכלול הקצאות והעתקה של זיכרון.
כשהרצתי את הקוד על קבצים די גדולים מסתבר שההקצאות האלו - אחרי פרופיילינג - לקחו הרבה מאוד זמן והאטו את התוכנה.
בחשיבה מחודשת על הפתרון הגעתי למסקנה שאני צריך לצמצם את כמות ההקצאות ולנסות להקצות הכל בבת אחת כמה שניתן.
למזלי הייתי יכול לחשב את גודל המידע לפי מטא-דאטה שהיה ברשותי ולכן הקצאתי הכל בבת אחת.
מהי הבעיה?
זה שיפר את הקוד כמעט פי 2 או 3!
לסיכום,
אופטימיזציות קוד זה דבר חשוב.
ביצועים ויעילות זה לא משהו שצריך לעבור על סדר היום ומפתחים טובים צריכים לדעת להתמודד עם האתגרים האלו.
דיברתי על ייעול זמן ריצה אך לא דיברתי על ייעול של תהליכים אחרים:
תחום היעילות בדומיין התוכנה הוא רחב, הרבה סודות עוד לפנינו!
אז תזכרו - אתם לא יכולים לשפר מה שאי אפשר למדוד.
ואתם לא יכולים למדוד אם אתם לא מכירים את הכלים למדידה.
ומה שמדדתם - ניתן לשפר.
תודה על הקריאה!