לפני שנה דיברתי על string builder, וחשבתי שהנושא די מוצה – מה עוד אפשר לומר עליו אחרי שהוכחנו שלפעמים הוא מהיר יותר מ-string ולפעמים לא?
אז מסתבר שלאובייקט string builder יש עוד כמה אספקטים.
ב-codeProject היה מאמר לא מזמן של מתכנת שהשתמש הרבה ב-string, וזה כמובן יצר לו בעיות של איטיות, וגם של זליגת זכרון. כדי להתגבר על הבעיות האלה הוא החליף את ה-string ב-string builder, ואכן בעיות המהירות נפתרו. דא עקא, שבעיות הזכרון לא נפתרו, והוא אפילו התחיל לקבל שגיאות system out of memory.
כזכור, כאשר אנחנו מוסיפים תוים ל-string קיים, המחרוזת הראשונית מושמדת, ונוצרת מחרוזת חדשה עם המקור+התוספת. ב-string builder לעומת זאת, מוקצה אורך ראשוני (ברירת המחדל היא 16 תוים), וכאשר מוסיפים עוד תוים למחרוזת, אם האורך עדיין פחות ממה שהוקצה אז התוים מתווספים למחרוזת המקורית, ורק אם האורך החדש גדול ממה שהוקצה – המחרוזת מועתקת ל-string builder חדש. כל פעם ש-string builder מעתיק את עצמו, הוא מקצה לעצמו אורך של פי 2 מהאורך הקודם.מסתבר שההקצאה המחודשת של פי 2 מהזכרון היא זו שיצרה בעיות זכרון אצל המחבר (אפשר לראות במאמר איך תוך 3 שניות המחרוזת הגיעה לאורך של 33.5 מליון תוים!).
הפתרון שלו היה ליצור מחלקה (class) שמחקה את העבודה של string builder, אלא שהיא מאפשרת להגדיר בכמה להגדיל את ההקצאה המחודשת. הוא מראה שם בצורה מאד יפה איך המחלקה שלו היא מהירה הרבה יותר מ-string, ואע”פ שהיא אינה מגיעה למהירות של string builder היא עדיין נמצאת באותו סדר גודל (מילי-שניות אצלו וב-string builder, לעומת כמה עשרות שניות ב-string). גם מבחינת שימוש ב-CPU ובזכרון המחלקה שלו עדיפה. כדאי לעיין קצת בתגובות, יש שם מגיב אחד שמתנגד מאד לשיטה שנקט בה המחבר.
ומאמר נוסף שפגשתי לאחרונה שגם קשור קצת לנושא, נכתב ע”י אחת מנותנות השרות במייקרוסופט ששמה הוא טס (Tess), שהבלוג שלה מטפל בענייני באגים בשרתי פרודקשן. במאמר שלה היא תוקפת את אותו נושא מכיוון אחר: איך מוצאים מה גורם לשימוש גבוה ב-CPU.
היא נותנת דוגמה לנתונים של שימוש גבוה ב-CPU, מנתחת אילו דברים יכולים לגרום לזה (יש 3: 1) לולאה אינסופית, 2) עומס גדול מדי [למשל, יותר מדי בקשות של דברים קטנים, כך שאף אחד מהדברים הקטנים אינו האשם], 3) שימוש גבוה מדי ב-Grabage Collcter), ומתארת את הטיפול באחד מהם (השלישי – שימוש גבוה מדי ב-Grabage Collcter. הטיפול בגורם הראשון הוא כמובן טיפול בלוגיקה שהובילה לזה, והטיפול בגורם השני הוא ע”י קניית חומרה נוספת ואופטימיזציה שלו). אח”כ היא מראה שם dump output שאפילו בשבילי יש שם יותר מדי 0 ו-1…. ובסוף היא מראה איך למעשה במקרה הזה כל העניין נבע משימוש ב-string לשרשור מחרוזות מאד ארוכות.
וכאן יש מאמר הרבה יותר טוב שלה בנושא, מהבחינה שהוא נועד ממש להדריך איך לעלות על בעיה של string משורשר מדי. המאמר הזה הוא חלקמסדרת הדרכות מעולה שהיא נתנה בנושאי דיבוג.
אז מסתבר שלאובייקט string builder יש עוד כמה אספקטים.
ב-codeProject היה מאמר לא מזמן של מתכנת שהשתמש הרבה ב-string, וזה כמובן יצר לו בעיות של איטיות, וגם של זליגת זכרון. כדי להתגבר על הבעיות האלה הוא החליף את ה-string ב-string builder, ואכן בעיות המהירות נפתרו. דא עקא, שבעיות הזכרון לא נפתרו, והוא אפילו התחיל לקבל שגיאות system out of memory.
כזכור, כאשר אנחנו מוסיפים תוים ל-string קיים, המחרוזת הראשונית מושמדת, ונוצרת מחרוזת חדשה עם המקור+התוספת. ב-string builder לעומת זאת, מוקצה אורך ראשוני (ברירת המחדל היא 16 תוים), וכאשר מוסיפים עוד תוים למחרוזת, אם האורך עדיין פחות ממה שהוקצה אז התוים מתווספים למחרוזת המקורית, ורק אם האורך החדש גדול ממה שהוקצה – המחרוזת מועתקת ל-string builder חדש. כל פעם ש-string builder מעתיק את עצמו, הוא מקצה לעצמו אורך של פי 2 מהאורך הקודם.מסתבר שההקצאה המחודשת של פי 2 מהזכרון היא זו שיצרה בעיות זכרון אצל המחבר (אפשר לראות במאמר איך תוך 3 שניות המחרוזת הגיעה לאורך של 33.5 מליון תוים!).
הפתרון שלו היה ליצור מחלקה (class) שמחקה את העבודה של string builder, אלא שהיא מאפשרת להגדיר בכמה להגדיל את ההקצאה המחודשת. הוא מראה שם בצורה מאד יפה איך המחלקה שלו היא מהירה הרבה יותר מ-string, ואע”פ שהיא אינה מגיעה למהירות של string builder היא עדיין נמצאת באותו סדר גודל (מילי-שניות אצלו וב-string builder, לעומת כמה עשרות שניות ב-string). גם מבחינת שימוש ב-CPU ובזכרון המחלקה שלו עדיפה. כדאי לעיין קצת בתגובות, יש שם מגיב אחד שמתנגד מאד לשיטה שנקט בה המחבר.
ומאמר נוסף שפגשתי לאחרונה שגם קשור קצת לנושא, נכתב ע”י אחת מנותנות השרות במייקרוסופט ששמה הוא טס (Tess), שהבלוג שלה מטפל בענייני באגים בשרתי פרודקשן. במאמר שלה היא תוקפת את אותו נושא מכיוון אחר: איך מוצאים מה גורם לשימוש גבוה ב-CPU.
היא נותנת דוגמה לנתונים של שימוש גבוה ב-CPU, מנתחת אילו דברים יכולים לגרום לזה (יש 3: 1) לולאה אינסופית, 2) עומס גדול מדי [למשל, יותר מדי בקשות של דברים קטנים, כך שאף אחד מהדברים הקטנים אינו האשם], 3) שימוש גבוה מדי ב-Grabage Collcter), ומתארת את הטיפול באחד מהם (השלישי – שימוש גבוה מדי ב-Grabage Collcter. הטיפול בגורם הראשון הוא כמובן טיפול בלוגיקה שהובילה לזה, והטיפול בגורם השני הוא ע”י קניית חומרה נוספת ואופטימיזציה שלו). אח”כ היא מראה שם dump output שאפילו בשבילי יש שם יותר מדי 0 ו-1…. ובסוף היא מראה איך למעשה במקרה הזה כל העניין נבע משימוש ב-string לשרשור מחרוזות מאד ארוכות.
וכאן יש מאמר הרבה יותר טוב שלה בנושא, מהבחינה שהוא נועד ממש להדריך איך לעלות על בעיה של string משורשר מדי. המאמר הזה הוא חלקמסדרת הדרכות מעולה שהיא נתנה בנושאי דיבוג.
מעניין ומועיל
תודה על הפוסט, מאוד ממצה