הסברים · אחד
רוב מה שהופך את הלקוח הזה למהיר אינו נתיב רשת מהיר יותר. זה שהנתונים נעים רק פעם אחת. הנה מה שזה אומר בפועל, למה זה דבר אחר מפריקה ישירה, אילו צורות ארכיון שורדות את זה, וכמה שווה באמת, על מכונה אמיתית, ביטול מחזור הכתיבה-והקריאה-חזרה.
נקודת המוצא
פרסום הוא אלפי מאמרות קטנות ומקודדות שיחד יוצרות מערך כרכי ארכיון, שבתורם מכילים את הקובץ שאתה באמת רוצה. המעבר מהאחד לאחר היה מסורתית ארבע משימות נפרדות, שכל אחת מסתיימת לפני שהבאה מתחילה.
כל שלב תקין, והתוצאה נכונה. אבל התוכן נכתב פעמיים, נקרא לפחות פעמיים, ובשיא היה על הדיסק להחזיק שני עותקים מלאים של משימה שרצית ממנה עותק אחד בלבד. השעון שאתה חווה הוא כל ארבעת השלבים ברצף, ולכן לקוח יכול לדווח על הורדה מהירה ועדיין להשאיר אותך ממתין.
השינוי
מעבר יחיד פירושו שהבתים עוברים מהרשת אל יעדם הסופי בלי להפוך אי פעם לקובץ ארכיון על הדיסק שלך. אין שלב שתיים או שלוש, כי העבודה של שניהם מתרחשת בזמן ששלב אחד עדיין רץ.
בפועל, כל מאמרה מפוענחת בזיכרון עם הגעתה ונמסרת ישר לשני דברים בו זמנית. המאמת בודק אותה מיד מול נתוני הזוגיות, כך שהתקינות נקבעת בזמן שהנתונים נוחתים ולא באמצעות קריאה חוזרת מאוחר יותר. המחלץ מתייחס לבתים הנכנסים כאל מיקום בתוך הארכיון, מחשב לאיזה חלק של איזה קובץ תוכן הם שייכים, וכותב אותם לשם.
כרכי הארכיון אינם מורכבים לעולם. הם קיימים כמבנה שהמחלץ מבין בזמן שההורדה באוויר, והדבר היחיד שמגיע לדיסק שלך הוא הקובץ שרצית. כשהמאמרה האחרונה מגיעה כמעט לא נותר מה לעשות, ולכן זמני הסיום שלנו קרובים לזמן ההורדה עצמו ולא להורדה בתוספת זנב.
התוצאה הנמדדת: לאותה משימה אנחנו כותבים בערך חצי, קוראים בחזרה הרבה פחות, וזקוקים בערך לגודל התוכן עצמו בשטח פנוי במקום לפי שניים ממנו. בגרסה של 190 GB אלה כ-157 GB שטח פנוי לעומת כ-313 GB, ובערך שליש מתעבורת הדיסק.
שני דברים הופכים את זה לקשה יותר משנשמע, והם הסיבה לכך שזה נדיר. המאמרות אינן מגיעות לפי הסדר, ולכן המחלץ חייב להתמודד עם בתים שנוחתים במיקומים שרירותיים ולא כזרם מההתחלה. וארכיון דחוס אינו ניתן לפריקה מהאמצע, ולכן כל חלק בעבודה שדורש באמת סדר חייב להיות מזוהה ומטופל אחרת ולא מוסר בהנחה.
ההשוואה ששואלים עליה
פריקה ישירה היא תכונה טובה והלקוחות שיש להם אותה טובים יותר בזכותה. היא גם פותרת חלק אחר של הבעיה, וההבדל מתגלה בדיוק במקום שבו הוא חשוב.
פריקה ישירה מתחילה לחלץ לפני שההורדה הסתיימה, כך ששלב שלוש חופף לשלב אחד במקום לבוא אחריו. מה שהיא אינה עושה הוא לבטל את שלב אחד. כרכי הארכיון עדיין נכתבים במלואם לדיסק שלך, כי הפורק הוא פורק רגיל שקורא קבצים רגילים; פריקה ישירה פשוט מפעילה אותו מוקדם יותר. שני העותקים עדיין קיימים, שתי הכתיבות עדיין מתרחשות, ודרישת השטח הפנוי אינה משתנה.
| לכתוב את הכרכים לדיסק | שטח פנוי נדרש | מספר הפעמים שהתוכן נכתב | |
|---|---|---|---|
| להוריד, ואז לפרוק | כן, ואז קריאה חוזרת | ~2× המשימה | 2 |
| פריקה ישירה | כן, נקרא בחזרה מוקדם יותר | ~2× המשימה | 2 |
| מעבר יחיד | לא נכתבים לעולם | ~1× המשימה | 1 |
ההבדל השני הוא מה שקורה כשהצורה אינה פשוטה. מכיוון שפריקה ישירה מוסרת עבודה לפורק רגיל ככל שהכרכים מופיעים, היא צריכה שהמצב יהיה פשוט: הכרכים נוכחים בסדר שמיש, אין תיקון בהמתנה, אין דבר שיש לפתוח קודם, וארכיון שתוכנו אינו בעצמו ארכיונים. כשאחד מאלה נכשל, הדבר ההגיוני הוא לסגת ולחזור לפריקה בסוף, וזה מה שקורה. אתה מקבל תוצאה נכונה ואת התזמון הרגיל.
מכיוון שהמחלץ שלנו בנוי מלכתחילה סביב בתים שלא לפי הסדר, המצבים האלה אינם חריגים עבורו. זו ההבחנה האמיתית: לא שאנחנו מתחילים מוקדם יותר, אלא שאיננו נשענים על תנאים שלעיתים קרובות אינם מתקיימים.
מה באמת שורד את זה
תכנון כזה שווה רק אם הוא חל על הפרסומים שאתה באמת פוגש, ולא על מקרה מיטבי נקי. המצב הנוכחי: אין פורמט מכולה שמטופל רק על הדיסק. RAR, 7z ו-zip עוברים כולם במסלול המעבר היחיד.
| צורה | מעבר יחיד | הערות |
|---|---|---|
| RAR, מאוחסן (ללא דחיסה) | כן | המקרה הנפוץ בגרסאות מדיה |
| RAR, דחוס | כן | כולל ארכיון דחוס כשכבה החיצונית |
| RAR 1.5, 3, 4 ו-5 | כן | כל ארבעת הדורות של הפורמט |
| 7z | כן | כולל תוכן דחוס ב-deflate |
| zip | כן | כולל תוכן bzip2 ו-LZMA |
| תוכן מוצפן | כן | עם סיסמה, כולל zip מוצפן |
| כותרות מוצפנות | כן | כשגם שמות הקבצים מוסתרים |
| שרשראות סיסמאות | כן | הסיסמה של כל שכבה ארוזה בשכבה שמעליה |
| ארכיונים מקוננים | כן | מפורקים מקינון תוך כדי, עד עומק הניתן להגדרה |
| פגום בכמה שכבות | כן | תיקון בכל רמה, עדיין מעבר אחד |
| מערכים מפוצלים במספור | כן | פיצולים בסגנון name.001 |
| ארכיונים המחלצים את עצמם | מעבר דיסק | הארכיון אינו מתחיל בתחילת הקובץ |
zip מפוצל (.z01) | מעבר דיסק | וכמה וריאנטים נדירים יותר של zip |
| משימות שחודשו | מעבר דיסק | משימה שממשיכה אחרי הפעלה מחדש מסתיימת בדרך הרגילה |
שלושת הסירובים הם כנים ומתנהגים באותו אופן: המשימה מסתיימת נכון, בדרך הרגילה, ואתה מקבל להורדה הזאת את התזמון הרגיל של שני עותקים. שום דבר לא נכשל; זה פשוט מפסיק להיות מהיר באופן שיתר העמוד הזה מתאר. ארכיונים המחלצים את עצמם נדחים מסיבה מבנית ולא מחוסר מאמץ, בכך שזיהוי ארכיון לפי הבתים הראשונים שלו אינו יכול לעבוד כשהבתים הראשונים הם תוכנית.
השורות של קינון והצפנה הן אלה ששווה להתייחס אליהן ברצינות, כי שם רוב הלקוחות מחזירים לך את המשימה. על מאגר מיוצר של עשר צורות מקוננות, המדורג לפי תקציר תוכן כדי שלקוח שמשנה את שם התוכן עדיין יזוכה, השלמנו 9 מתוך 10 בלי התערבות; הלקוח הבא בטיבו השלים 5, ושניים אחרים השלימו 2. זו שאיננו משלימים אוטומטית היא סולם של עשר רמות, שמסתיים נקי במגבלת העומק שברירת המחדל שלה היא חמש ומשאיר את השכבה העמוקה ביותר כארכיון תקין, ומושלם במלואו אם תעלה את המגבלה. הסבבים האלה נמצאים בעמוד בדיקות הביצועים עם הטבלה המלאה.
למה שווה לעשות את זה
זה מהיר יותר, מסיבה לא זוהרת. כתיבת 60 GB וקריאתם בחזרה אינה חינם אפילו בכונן SSD מהיר, ובכל דבר איטי יותר זה לעיתים קרובות צוואר הבקבוק האמיתי ולא הרשת. ביטול כתיבה אחת ושתי קריאות מסיר את הזמן הזה מהשעון שלך לגמרי. הרווח גדול ביותר בדיוק היכן שהכי שמים לב: משימות גדולות, ומכונות שהדיסק שלהן אינו החלק המהיר בהן.
זה מקטין את הבלאי בחצי. לכונני SSD יש מספר סופי של כתיבות, ומוריד שכותב כל תוכן פעמיים מוציא את התקציב הזה בקצב כפול בלי שום תועלת עבורך. על פני כמה מאות טרה-בתים של הורדה, שזו שנה רגילה למשתמש פעיל, ההפרש הוא חלק משמעותי מחיי הכונן.
זה משנה מה נכנס. שטח פנוי אינו מאפיין ביצועים, הוא כן או לא. משימה שדורשת פי שניים מגודלה כמרווח או רצה או לא. הצורך בערך בגודל התוכן פירושו שמשימות מסתיימות במכונות ובכוננים שבהם הגישה הרגילה פשוט נעצרת, ולכן גרסה של 190 GB נכנסת כאן בכ-157 GB שטח פנוי ולא בכ-313 GB.
זה עולה פחות זמן מעבד. אי-העברת נתונים דרך הדיסק פעמיים מסירה את העבודה הכרוכה בכך, ואימות במהלך ההורדה פירושו אין מעבר שני על התוכן כדי לבדוק אותו. עלות המעבד שלנו נשארת שטוחה על כ-1.7 שניות מעבד לג'יגה-בית, ממשימה של 35 GB ועד למשימה של 190 GB, וזו התכונה המועילה: העלות לג'יגה-בית אינה גדלה כשהמשימה גדלה.
זה רץ בפחות זיכרון, ובזיכרון חסום. מכיוון שהבתים נצרכים עם הגעתם ולא נצברים, קבוצת העבודה היא תקציב שאתה קובע ולא פונקציה של גודל המשימה. זה מה שמאפשר לעבד גרסה של 190 GB במכונה שבה זמינים בערך 1.1 GB. ההבחנה החשובה אינה המספר אלא הצורה: זיכרון שגדל עם המשימה ייתקל בסופו של דבר במשימה שהמכונה שלך אינה יכולה לסיים, והוא נכשל בהחלפה לדיסק או בהריגה ולא בכך שיאמר לך.
בסך הכול, מדובר פחות בזכייה במדידה ויותר בשאלה היכן התוכנה יכולה לרוץ בכלל. תכנון שדורש חצי מהשטח הפנוי, חצי מהכתיבות וכמות זיכרון חסומה עובד על שרת ביתי קטן, מחשב נייד ישן יותר או NAS, ושם חלק ניכר מהתוכנה הזאת באמת חי.
כל נתון בעמוד הזה נמדד ומפורסם עם הגרסה והתאריך לצידו בעמוד בדיקות הביצועים, כולל הסבבים שאנחנו מפסידים. משקל הנגד הכן, שנאמר גם שם: מחלץ ומתקן שנבנו כדי לרכוב על הורדה חיה מחזיקים יותר זיכרון תושב מכלי עצמאי שמורץ פעם אחת משורת הפקודה, ולכן אם האילוץ שלך הוא טביעת הרגל הקטנה ביותר האפשרית למשימה חד-פעמית על קובץ שכבר יש לך, הכלים הייעודיים מנצחים בעמודה הזאת.