בעקבות ההודעה הזו - http://www.fresh.co.il/vBulletin/sh...400&postcount=7 החלטתי לבדוק שוב את עניין החיבור בין מחרוזות. פתחתי טופיק חדש מכיוון שהנושא של הטופיק הישן לא ממש התאים ולדעתי זה נושא שחשוב לדון בו בהקשר ליעילות קוד.

השתמשתי באותה המחלקה עם שלושת הבדיקות:

• חיבור רגיל - "Variable = Variable + "String.
• חיבור =+ - "Variable += "String
• שימוש במחלקה שמוסיפה למערך איבר בכל איטרציה.

השינוי המהותי בין הבדיקה הזו והבדיקה הקודמת הוא שרשור מחרוזות כחלק מהגדרת המשתנה, שנראה כך:

קוד:

sStr = sStr + " " + sStr + " " + sStr + " ";

בשימוש =+:

קוד:

sStr += " " + sStr + " " + sStr + " ";

ובשימוש במחלקה:

קוד:

sString.add(" " + sStr + " " + sStr + " ");

(בנוסף, הקטנתי את מס' האיטרציות ל-100).

התוצאות השתנו במעט. תחת IE התוצאות היו אלו:

• בשימוש רגיל - 193844 מילישניות.
• בשימוש =+ - 609 מילישניות
• בשימוש מחלקה - 422 מילישניות.

FF החליט לסיים את פעולת הסקריפט לאחר מס' שניות בטענה שנגמר לו הזיכרון.

אשמח לשמוע הערות ותוצאות שלכם מבדיקה של הדף (לוודא שזו לא בעיה מקומית אצלי).
הערה חשובה: הסקריפט גורם לתקיעה ארוכה ולזלילת משאבים מהמחשב ויכול לגרום לקריסת הדפדפן. (במיוחד אם אתם משתמשים באקספלורר )

https://2006-uploaded.fresh.co.il/2...05/51593702.htm
לצפיה במקור:
http://view-source:https://2006-upl...05/51593702.htm
הערה נוספת: במהלך הבדיקות ופרסום חוזר של ההודעה עשיתי טעות קטנה בסקריפט (לא ניקיתי את המחרוזת לפני הבדיקה השניה), מה שגרם ל-IE להתקע למשך פרק זמן ארוך ביותר (20 דקות) לפני שהבנתי שמזה הוא לא יצא - מה שמלמד אותי ש-IE הוא לא חכם במיוחד...


תודה,
שחר

בהחלט "בנצ'מרק" מועיל. כרגע הרסת הרבה קודים של אנשים שהשתמשו בשיטה הראשונה שכתבת לחיבור מחרוזות... כמעט כולם כותבים בשיטה הזאת, וגם אני כתבתי ככה עד עכשיו

תודה רבה - אני ממליץ להכניס לארכיון.

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

לפי הבדיקות שעשית השרשור בשיטה הראשונה לוקח כ-3 דקות, או לפחות כ-2 דקות (בהרצת הקוד אצלי תחת אוונט-אקספלורר).
בנינו... לא ביצענו שרשור מחרוזות ארוכות בהרבה באותה שיטה ואף פעם לא ראינו את FF למצמץ ?! אז כנראה שהבדיקה לוקה משהו בחסר, צריך רק להבין למה ולמצוא היכן טמון הכלב (או הארנב - בשביל דור).

אני מסכים עם שני הדברים שנאמרו
אני גם לא כל כך מבין מאיפה ההבדל בין הבדיקות יכול לנבוע, אולי מישהו מפורום תיכנות?
הדבר היחידי שאני יכול לחשוב עליו הוא שהסימן + נוגע גם לחיבור חשבוני וגם לשרשור מחרוזות, אז אולי זה מעובד בצורה כזו שהוא מנסה לחבר "חשבונית" ואז מחרוזת.
זה נורא מוזר כיוון שיצירת מערך, ועוד פעולות עליו, למעשה אמורות לקחת יותר זמן משרשור מחרוזות.

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

אני יודע למי זה כן יכול לעזור, יש פורומים שנכתבים כך שכל התוכן מועבר לצד הגולש ומעובד שם בעזרת JS. (ראה ערך webmaster.org.il
וכמובן שזה יעזור לי, אני אשתמש בזה מעכשיו (או בעצם, מהפוסט הקודם), תודה רבה


ד"א, אני בעבודה, תקעת לי את המחשב עם הדף הזה.
יצאתי להפסקה.. חזרתי.. והוא עדיין לא סיים :\ (ככה שאפילו לא יצא לי לראות את הקוד מקור)

1. בענין פעולת השרשור - לא בדקתי את הקוד מקור, אך הגיוני שנעשה כאן פשוט תנאי הבודק אם תוכן המשתנה/ים הוא מחרוזת או מספר ובהתאם לכן מבוצע פעולת חיבור או שרשור.
2. הגם ולמרות שזה נעשה בצד הלקוח זה חשוב מאד, לעיתים רבות קוד JS בעל מספר שורות בודדות גורם לתקיעת הדפדפן אצל הלקוח ומשכנעו להמנע מהמשך הגלישה באתר...
אגב, במערכות מבוססות יותר על צד הלקוח (כגון JS + XML) זה כמובן נהפך להרבה יותר קריטי.

ובהמשך לדבריי מהודעתי לעיל, כתבתי מערכת מבוססת JS + XML שבה מנוע הדפדפן צריך לנתח קובץ XML המכיל כ-16,000 שורות קוד, לבצע עשרות לולאות בכל דף, ובמיוחד - מאות (אם לא אלפי) שרשורים למחרוזת אחת ארוכה המכילה כמעט את כל תוכן הדף (תוכן הדף מוצג רק לאחר סיום כל הפעולות). ולמרות שיש השהיה של כשניה (לעיתים יותר לעיתים פחות) זה לא מתקרב לתוצאות הבדיקות שמראות ששרשור מספר מחרוזות בודדות בשיטה הזאת נמשכות כ-180 שניות !
כך שזה די מוזר, וכמו שאמרתי, צריך להבין מה באמת גורם לקוד להיות איטי.

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

ליכולות של דפדפן זה או אחר.
אתה יותר שואל פה איזה דפדפן מנהל זיכרון יותר טוב מאשר איזה דפדפן ואיזו שיטה משרשרים סטרינגים יותר טוב.

בנוסף , אני מעריך ש- += מהיר יותר מהצורה הרגילה (בהרבה) שוב, בגלל בעיות זכרון.
ברגע שאתה משתמש ב+= , הדפדפן רק צריך למצוא עוד מקום לשים בו את המידע, אשכרה לשים , ולקשר אותו עם שארית הסטרינג. (אני מאמין שהוא עובד בצורה הזאת)
במקום זה, בצורה הרגילה, הוא מעתיק את כל הזכרון שוב, וזה מה שגורם לו ליתר עבודה.

בקיצור, הבדיקה שגויה בתכליתה. עדיף להריץ קטע קוד שמוסיף כל פעם 5-10 אותיות , ומבצע זאת כמה עשרות אלפי פעמים.