טיפים להאצת Visual Studio

25 במאי 2012

אין תגובות

מפתחים רבים מבקשים את עזרתי בפתרון בעיות של ביצועי Visual Studio.
בד”כ את רוב הבעיות ניתן לפתור יחסית בקלות,
וככל שעובר הזמן אני מוצא את עצמי מספק פחות או יותר את אותן התשובות,
מה שגרם לי לחשוב שכנראה הגיע הזמן להעלות אותן בצורה מסודרת לפוסט.

Photo by Balaji Dutt

מעבר לזה, פעמים רבות אני מוצא מפתחים ש”סובלים” מאיטיות,
מבזבזים זמן פיתוח יקר,
כאשר בכמה צעדים פשוטים ניתן לשפר את המצב משמעותית.

קשה לחזות אילו מהטיפים יהיו אפקטיביים יותר עבור כל מקרה,
לכן מומלץ לעבור על כולם ואז לראות מה השיפור שהושג.
צריך גם לזכור, שהתוצאה הסופית לא תהיה תלויה רק בקונפיגורציה נכונה של הסביבה,
שכן אין תחליף לחומרה המתאימה לסביבת פיתוח.

מביקורי אצל לקוחות אני יכול לדווח שבד”כ מעבר על כל הטיפים משיג שיפור ביצועים של עשרות אחוזים
בפעולות שכיחות.

ואילו הטיפים:

  • הגדרות סימבולים
    • בדקו האם מוגדר לכם משתנה סביבה בשם:
      • משתנה זה יגרום ל Visual Studio לנסות ולטעון סימבולים גם כשלא התכוונתם לכך,
        ואין אפשרות לכבות את זה מתוך Visual Studio.
      • אם אין לכם צורך שוטף במשתנה זה, מומלץ למחוק את משתנה הסביבה הזה ולאתחל את Visual Studio.
    • בדקו האם ישנם הגדרות נוספות לטעינת סימבולים בתוך Visual Studio:
      • Tools –> Options –> Debugging –> Symbols

      image

      • כדאי לעבור על הרשימה ולהסיר כל Location שאינו נחוץ, במיוחד כאלו שאולי מצביעים לאינטרנט או ל network shares.

 

  • תמיכה ב Unmanaged Debugging
    • עבודה עם Visual Studio במצב תמיכה ב Unmanaged Debugging מאטה את העבודה בצורה משמעותית. ברוב המקרים הדבר אינו נחוץ לעבודה שוטפת.
      מפתחים נוהגים להדליק את האופציה במקרה הצורך, ומשאירים אותה גם לאחר שכבר לא צריך.
    • בדקו האם הפרויקט שלכם מוגדר לתמוך ב Unmanaged Debugging והסירו את האופציה אם אינכם זקוקים לה באופן שוטף.
      • Project Properties –> Debug –> Enable Debuggers –> Enable unmanaged code debugging
        image

 

  • ניהול תוספים ל Visual Studio
    • זהו אחד הגורמים המשמעותיים ביותר להאטה.
      למעשה ברגע שהתקנו תוסף,פוטנציאלית תיתכן האטה משמעותית במקרים בהם בתוסף שהותקן ישנן בעיות ביצועים, והוא יכול להשפיע על חווית השימוש הכללית, גם בתסריטי שימוש שאולי לא נראים לנו  קשורים לתוסף המדובר.
    • לעיתים אין תוסף אחד שגורם לבעיה, אלא שילוב של תוספים רבים שמותקנים, וכל אחד מהם תורם להאטה בצורה מצטברת…
    • מומלץ להסיר תוספים שאינם בשימוש שוטף, או שאינם נחוצים עוד.
    • במקרה שהתגלה תוסף שגורם לבעיות ביצועים, מומלץ ליצור קשר עם הגורם שפיתח אותו לקבלת תמיכה. במקרים שאין אפשרות לקבל פתרון, נצטרך לבצע החלטה – האם היכולות שמעניק לנו התוסף “שוות” את האיטיות שהוא מוסיף לעבודה.
    • האופן הפשוט ביותר לזיהוי תוספים בעייתיים מתבצע בצורה של “ניסוי וטעיה”
      כאשר מסירים את כל התוספים, ומחזירים אותם אחד אחד תוך כדי מדידה בשביל לדעת מה ההשפעה שגורם כל תוסף.
      • ישנם מספר מקומות בהם ניתן למצוא את התוספים:
        • Tools –>Add-in Manager

        image

          • ההסרה מתבצעת באמצעות ביטול כל ה Checkboxes.
        • Tools –> Extensions Manager

        image

          • את חלק מהתוספים ניתן לבטל זמנית בקלות ע”י לחיצה על כפתור ה Disable
          • אחרים ידרשו לחיצה על Uninstall כדרך היחידה לבטלם.
          • לעיתים יהיו תוספים כאלו שידרשו הסרה חיצונית מחלונית ה “Add or remove programs

         

  • איחוי דיסק
      • תהליכי הקומפילציה שמפתחים מריצים באופן שוטף גורמים לפרגמנטציה מוגברת בדיסק,
        מה שיכול להאט את פעולת הדיסק באופן משמעותי ולהשפיע על ביצועים.
      • מומלץ להגיע למצב שבו הפרגמנטציה בדיסק מערכת ההפעלה ובדיסק שמכיל את סביבת העבודה ( אם אינו זהה), קרובה ל 0%.
      • מומלץ לקבוע תהליכי איחוי אוטומטיים שירוצו במהלך הלילה (יומי או שבועי) כך שלא תצטבר פרגמנטציה בדיסק.

 

  • מקום פנוי בדיסק
      • מחסור של מקום בדיסק הקשיח יכול להשפיע על הביצועים באופן עקיף
        • איחוי דיסק שאינו יעיל מספיק
        • איטיות בכתיבה עקב מחסור בשטח רציף מספיק בדיסק
      • כמינימום מומלץ להשאיר לפחות 15% מקום פנוי בדיסק.
        אישית, אני נוהג להשאיר סדר גודל של כ 30% פנוי כדי להשיג ביצועים מיטביים,
        אם כי אין זה מספר שמומלץ בצורה רשמית למיטב ידיעתי.

 

  • מהירות הדיסק הקשיח
    • למחשב פיתוח מומלץ לעבוד עם דיסק קשיח במהירות של לפחות 7200RPM, ומומלץ 10000RPM.
    • במחשבים ניידים ניתן עדיין למצוא דיסקים במהירות של 5400RPM, והם פחות מומלצים לפיתוח.
    • דיסקים מסוג SSD יותר ויותר נפוצים היום, ויכולים לספק ביצועים מיטביים למחשב פיתוח.
      כמו כן, שימוש ב SSD, מונע את הצורך בתהליכי איחוי הדיסק שהזכרתי למעלה.
      אכן, נכון לכתיבת שורות אלו מדובר בעלויות גבוהות משמעותית מדיסקים מגנטיים מקבילים בגודל,
      אך לטעמי שיפור הביצועים מחזיר את העלות יחסית מהר, בעיקר אם מתפשרים על נפח קטן יותר.
    • שילוב של SSD ו Windows 7 יכול לספק ביצועים טובים אף יותר.

 

  • התקנה סדירה של תיקונים (Patching)
    • Visual Studio מקבל עדכונים באופן שוטף, וחשוב להתקין אותם באמצעות Windows Update גם אם הם מוגדרים Optional. דגש מיוחד עבור התיקונים האלו עבור Visual Studio 2010 שמוכרים כמשפרי ביצועים:
    • ניתן לאתר תיקונים נוספים (חלקם אינם מופצים דרך Windows update )
      באמצעות אתר ה Connect תחת הקטגוריה של Visual Studio
      מומלץ לעבור מעת לעת על התיקונים שמופצים באתר, ובמידה ונתקלתם בבעיה שמקבלת מענה שם, אפשר להוריד את התיקון ולהתקין אותו.

 

  • עבודה תקינה עם המאיץ הגרפי (GPU)
    • Visual Studio מבוסס בחלקו על WPF. במקרה של בעיות עם המאיץ הגרפי, יכולים להיווצר סימפטומים של בעיות ביצועים בזמן ריצה ( ולעיתים אפילו שגיאות).
    • מומלץ לוודא שהמאיץ הגרפי מותקן עם דרייברים עדכניים ללא תקלות שמדווחות ע”י Windows.
    • מומלץ להשתמש במאיץ גרפי שתומך כראוי ב WPF.
    • במקרים קיצוניים ניתן לבדוק אם מצליחים להשיג שיפור באמצעות ביטול ה Visual experience
      • Tools—> Options –>Environment –>General—> Visual experience

      image

 

  • ניצולת זיכרון
    • devenv.exe (סביבת הפיתוח של Visual Studio) אמנם מקומפלת רק ל 32 ביט, אבל עם דגל LARGEADDRESSAWARE .
      • זה אומר שאם אתם עובדים בחוכמה ורצים עם מערכת הפעלה של 64 ביט, תוכלו לקבל מרחב זיכרון וירטואלי של עד 4GB עבור הסביבה.
      • אם אתם עובדים עדיין עם מערכת הפעלה של 32 ביט, אז כברירת מחדל תקבלו מרחב זיכרון של עד 2GB. בחלק מהמחשבים ניתן להגדיל זאת ל 3GB בעזרת קונפיגורציה של “3gb/
        • שימו לב: זהו שינוי ברמת מערכת ההפעלה שיכול להשפיע על מגוון תוכנות אחרות במחשב, ובמקרים מסוימים אף למנוע עליה תקינה של מערכת ההפעלה!
          אם החלטתם לנסות, כדאי להגדיר את האופציה כקונפיגורציה נוספת ב boot.ini ולא להחליף את הקיימת.
    • מדוע זה חשוב?
      • ניצולת הזיכרון של סביבת העבודה יכולה לגדול משמעותית, בעיקר במקרים בהם יש עבודה עם הרבה תוספים, תוספים כבדים או עבודה אינטנסיבית עם ה Designer. עומס זיכרון זה יכול להתבטא באיטיות, ולפעמים אף בהודעות שגיאה הדורשות אתחול מלא של סביבת העבודה.
      • לביצועים אופטימליים של סביבת העבודה, מומלץ לעבוד עם מערכת הפעלה של 64 ביט,
        גם אם אתם מפתחים אפליקציה שמקומפלת ל 32 ביט.
    • שימו לב שאין קשר ישיר בין כמות ה RAM הפיסי המותקן לכם במחשב לבין מרחב הכתובות הוירטואלי של תהליך סביבת העבודה.
      כמובן שיותר RAM יוכל לשפר ביצועים, שכן השימוש ב pagefile יוכל להצטמצם משמעותית.
      לעמדת מפתח מודרנית ויעילה אני ממליץ כיום על לפחות 8GB RAM, ועדיף 16GB.

 

  • מערכת הפעלה מודרנית
    • בביקורי אצל לקוחות אני עדיין פוגש כאלו שמפתחים על סביבות מיושנות כדוגמת Windows XP.
      אני יודע ש XP מערכת נהדרת, אבל יש היום את Windows 7 שטובה ממנה משמעותית,
      ובקרוב גם את Windows 8.
    • מערכת הפעלה מודרנית, בשילוב עם גרסת 64 ביט, תספק סביבת עבודה משופרת לתכניתן,
      בין השאר: אפשרות לניצול יותר זיכרון במכונה, ניצול יותר ליבות, עבודה יעילה יותר עם SSD וכד’.
    • אני ממליץ לעבוד עם UAC דלוק כדי לוודא שהאפליקציה מותאמת לריצה ללא Elevation כבר בשלב הפיתוח.

 

  • אנטי וירוס
    • אין ספק שנוכחות של תוכנת אנטי וירוס היא כורח המציאות על כל מחשב.
    • נתקלתי בארגונים בהם קונפיגורציית האנטי וירוס הייתה מאוד אגרסיבית,
      וגרמה לירידת ביצועים משמעותית בסביבת הפיתוח.
    • אני מאמין שבעבודה משותפת של גורמי הפיתוח בארגון יחד עם אנשי ה Security שלו,
      ניתן להגיע לקונפיגורציה יעילה ומאוזנת שתספק הגנה יעילה מחד אך לא תפגע מידי בביצועים מאידך.
    • דברים שניתן לבדוק לדוגמא: האם יש ערך הגנתי משמעותי בסריקת כל קובץ cs ש devenv קורא/כותב? מה לגבי קבצי xml או xaml ?

 

  • ריבוי פרויקטים ב Solution
    • ריבוי פרוייקטים תחת sln בודד משפיע משמעותית על זמן הטעינה של סביבת העבודה.
    • קבצי sln המכילים עשרות פרויקטים נוטים לבעיות ביצועים בסביבת העבודה,
      ולרוב לא מסיבות מוצדקות.
    • פתרונות ששווה לשקול:
      • האם באמת נחוצים כל הפרויקטים ב sln לצורך הפיתוח השוטף?
        לעיתים כדאי להגדיר “פרופילים” שונים של sln למשימות שונות המתרחשות בתדירויות שונות.
      • איחוד פרויקטים. ראיתי לא מעט מקרים בהם היו 2 פרויקטים או יותר שיכלו בקלות לשבת בפרויקט אחד… הם מכילים תלויות דומות, תמיד מותקנים יחד וכד’. בד”כ כשחוקרים את המקור לפיצול, מתברר שתכניתנים החליטו לפתוח פרויקט חדש כדי להקטין כמות התנגשויות בקובץ ה csproj. עבודה נכונה יותר תשתמש בשילוב של Multiple Checkout עם Branching.
        בכל מקרה, מומלץ לאחד פרויקטים כאלו לפרויקט אחד. כבר ראיתי לקוחות שהורידו את כמות הפרויקטים ב 50%  וביצועי סביבת הפיתוח השתפרו משמעותית…

 

  • שימוש יעיל בליבות המעבד
    • במחשבי פיתוח מודרניים ניתן למצוא כיום כמות ליבות מכובדת ביותר, מ 2 ועד 6 ליבות
      וזה עוד לפני Hyper Threading.
    • אחת הדרכים לנצל את כמות הליבות לקומפילציה מהירה יותר היא שימוש ביכולות הקומפילציה המקבילה של MSBuild.
    • טריק” נוסף מאפשר להפעיל את MSBuild מתוך סביבת העבודה בצורה יחסית “שקופה”.
      • שימו לב שלצורת עבודה זו ישנם גם חסרונות, ומומלץ לקרוא את הפוסט במלואו לפני שרצים לממש.
      • אני כן יכול לדווח שבשבוע שעבר עשיתי ניסוי עם לקוח של קומפילציית פרויקט WPF די גדול, והצלחנו להוריד את זמן הקומפילציה מ 2 דקות לדקה אחת בלבד!
    • שימו לב ש”עץ התלויות” בין הפרויקטים שלכם ישפיע מאוד על יעילות השימוש במקביליות.
      • עצי תלות בעומק נמוך יחסית יוכלו ליהנות משיפור משמעותי יותר מכאלו בעלי עץ תלויות עמוק, שכן כל עוד לא קומפלו פרויקטים “בראש עץ התלויות” לא ניתן להתחיל לקמפל פרויקטים אחרים. במקרים של עץ תלויות עמוק, ייתכן שעבודה מקבילית אף תיתן ביצועים נחותים מקומפילציה סדרתית רגילה.

 

  • חומרה מותאמת לפיתוח בטכנולוגיה עדכנית
    • ציינתי אוסף לא קטן של טיפים שיכולים לסייע ולשפר את חווית הפיתוח משמעותית.
      עדיין, במקרה של שימוש בחומרה ישנה, ישנו גבול עד כמה ניתן לשפר ביצועים.
    • ביקרתי לא מזמן אצל לקוח, שנותן למפתחים שלו לעבוד עם מחשבים מודל 2005,
      מעבד Pentium D, ו 1GB של RAM. התכניתנים עובדים עם Windows XP, מנסים לפתח אפליקציות WPF עם Visual Studio 2010 ומבזבזים זמן רב בלחכות למחשב…
      בפועל מה שהלקוח מנסה לעשות זה לפתח באמצעות טכנולוגיה מהשנים 2010-2012 עם פלטפורמה של שנת 2005. מה שמדהים הוא שמנהלים בארגונים כאלו לא רואים את הבעיה,
      וגורמים לבזבוז משאבים אדיר של ההון האנושי.
      זה בערך כמו להשתמש במרכב של פרארי עם מנוע של סוסיתא…
      זה אולי יראה יפה מבחוץ, אבל התוצאות בשטח לא יהיו משהו…
    • גד מאיר כתב פוסט שמאוד אהבתי על הנושא. אני ממליץ לכם לקרוא אותו ולא ארחיב יותר כאן.

 

 

  • מה קורה אם ניסיתם את כל הטיפים, החומרה אמורה להיות מספיק חזקה
    ועדיין ישנם בעיות לא מוסברות?
    • ישנם מקרים יחסית נדירים שיביאו לבעיות ביצועים ולא יפלו תחת הקטגוריות הנ”ל.
    • במקרים כאלו אני ממליץ לבדוק את ביצועי הסביבה באמצעות כלי כדוגמת Procmon של Sysinternals, ולנסות לזהות גורמים “מעכבים” בתסריטי שימוש שונים בסביבת הפיתוח.
    • למי מכם שעדיין אינו מכיר את הכלי,
      מומלץ להתרשם מצפיה בסדרת “Case of the Unexplained” של מארק רוסינוביץ’.

 

בברכת קומפילציה מהירה,

אלי.

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *