מדוע התקדמות ברים כל כך לא מדויק?

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

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

כל המשימות לא נוצרו שווים

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

שקול את המשימות הבאות המתבצעות על-ידי תוכנית התקנה:

1. צור מבנה תיקיות.
2. לדכא ולהעתיק 1 GB בשווי של קבצים.
3. צור ערכי רישום.
4. יצירת ערכי תפריט התחלה.

בדוגמה זו, השלבים 1, 3 ו- 4 יושלמו מהר מאוד, בעוד שלב 2 ייקח קצת זמן. אז בר התקדמות לעבוד על ספירה פשוט יקפוץ ל 25% מהר מאוד, דוכן קצת בשלב 2 עובד, ואז לקפוץ ל 100% כמעט מיד.

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

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

1. צור מבנה תיקיות. [משקל = 1]
2. לדכא ולהעתיק 1 GB בשווי של קבצים. [משקל = 7]
3. צור ערכי רישום. [משקל = 1]
4. יצירת ערכי תפריט התחלה. [משקל = 1]

באמצעות שיטה זו, התקדמות בר היה לנוע במרווחים של 10% (כמו המשקל הכולל הוא 10) עם צעדים 1, 3, ו 4 להעביר את הבר 10% על השלמת שלב 2 להעביר אותו 70%. אמנם בהחלט לא מושלם, שיטות כמו זו הן דרך פשוטה להוסיף קצת יותר דיוק את אחוז התקדמות בר.

תוצאות העבר לא מבטיח ביצועים עתידיים

חשבו על דוגמא פשוטה שאני מבקשת מכם לספור עד 50 בזמן שאני משתמשת בשעון סטופר בזמן. נניח שאתה סופר ל -25 ב -10 שניות. סביר להניח שתספור את יתרת המספרים ב -10 שניות נוספות, כך שבסרגל ההתקדמות יעקוב אחר 50% עם 10 שניות שנותרו.

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

לקבלת דוגמה מעשית יותר של זה, שקול להוריד קובץ. אתה מוריד כרגע קובץ 100 MB בקצב של 1 MB / s. זה מאוד קל לקבוע את זמן ההשלמה המשוער. אבל 75% מהדרך שם, כמה הלהיטים ברשת ואת קצב ההורדה שלך יורד ל 500 KB / s.

בהתאם לאופן שבו הדפדפן מחשב את הזמן שנותר, זמן ההגעה המשוער שלך יכול לעבור באופן מיידי מ -25 שניות ל -50 שניות (במצב הנוכחי בלבד: גודל שנותר / מהירות הורדה) או, ככל הנראה, הדפדפן משתמש באלגוריתם ממוצע מתגלגל אשר יהיה להתאים את תנודות מהירות ההעברה מבלי להציג קפיצות דרמטית למשתמש.

דוגמה לאלגוריתם מתגלגל בנוגע להורדת קובץ עשויה לפעול כך:

• מהירות ההעברה של 60 השניות הקודמות זוכרת עם הערך החדש ביותר המחליף את הישן ביותר (למשל, הערך 61 מחליף את הראשון).
• שיעור ההעברה האפקטיבי לצורך החישוב הוא ממוצע המדידות.
• הזמן שנותר מחושב כ: גודל שנותר / יעיל להוריד מהירות

אז באמצעות תרחיש שלנו לעיל (למען הפשטות, נשתמש 1 MB = 1,000 KB):

• ב 75 שניות לתוך ההורדה, 60 ערכים לזכור שלנו יהיה כל 1,000 KB. שיעור ההעברה האפקטיבי הוא 1,000 KB (60,000 KB / 60) אשר מניב זמן שנותר של 25 שניות (25,000 KB / 1,000 KB).
• ב -76 שניות (כאשר מהירות ההעברה יורדת ל -500 KB), מהירות ההורדה האפקטיבית הופכת ל -992 KB (59,500 KB / 60) אשר מניבה זמן שנותר של 24.7 שניות (24,500 KB / 992 KB).
• ב -77 שניות: מהירות אפקטיבית = ~ 983 KB (59,000 KB / 60) נותרה זמן הנותר של ~ 24.4 שניות (24,000 KB / 983 KB).
• ב -78 שניות: מהירות אפקטיבית = 975 KB (58,500 KB / 60) נותרה זמן הנותר של ~ 24.1 שניות (23,500 KB / 975 KB).

אתה יכול לראות את דפוס המתעוררים כאן כמו לטבול מהירות ההורדה הוא איטי משולב לתוך הממוצע שבו נעשה שימוש כדי להעריך את הזמן הנותר. תחת שיטה זו, אם הטבילה נמשכת רק 10 שניות ולאחר מכן חזר ל 1 MB / s המשתמש סביר להבחין ההבדל (למעט דוכן קטן מאוד הספירה לאחור הזמן המשוער).

להגיע לנעצים פליז - זה פשוט מתודולוגיה להעברת מידע למשתמש הקצה עבור הגורם הבסיסי בפועל ...

אתה לא יכול לקבוע במדויק משהו כי הוא nondeterministic

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

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

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

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

בסופו של דבר, זה באמת לא משנה

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

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