איך משווים נכון מהירות בין גרסאות תוכנה ב-Windows

רוצים להשוות בין גרסה A לגרסה B של תוכנה ב-Windows. מה שהכי אסור לעשות אז הוא להריץ פעם אחת בכל גרסה על אותו מחשב ולומר “נראה ש-B מהיר ב-8%”.

ייתכן שה-8% האלה הם באמת הבדל קוד. אבל בפועל, הסיפור הנפוץ ב-benchmark ל-Windows הוא שמצב חשמל,‏ power plan, חום, עדכונים ברקע, אינדקס חיפוש, סריקת אנטי-וירוס,‏ affinity, סדר ההרצה, מצב מטמון — אחד מאלה הוא הגורם. זו עבודה שקטה של סתימת תנאים אחד אחד.

flowchart TB
    accTitle: הזהות האמיתית מאחורי "נראה שמהיר ב-8%"
    accDescr: תרשים המראה שהבדל שיוצא מהרצה בודדת בכל גרסה עשוי להיות הבדל קוד, אבל בפועל בדרך כלל זה חשמל, חום, רעש או מטמון, ונדרשת עבודה של סתימת תנאים אחד אחד.
    one1["הרצה בודדת בכל גרסה, השוואה"] --> dif2["מתקבל 'נראה שמהיר ב-8%'"]
    dif2 -->|"ייתכן"| code1["הבדל קוד אמיתי"]
    dif2 -->|"הזהות הנפוצה"| env1["חשמל · חום · רעש · מטמון"]
    env1 --> crush1["סתימת התנאים אחד אחד"]

איור 1: הבדל מהרצה בודדת לא בהכרח הבדל קוד — אי אפשר לקבוע עד שלא סותמים את התנאים.

במאמר הזה נסכם דרך להשוות מהירות הרצה בין גרסאות שונות של תוכנה ב-Windows, כמה שיותר קרוב להבדל הקוד עצמו. היעד הוא בעיקר Windows 11, אבל רוב powercfg ו-start וכדומה עובדים באותה צורה גם ב-Windows 10.

מונחים שכדאי לקבוע מראש

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

קודם המסקנה

אם מחלצים את מה שמשפר שחזוריות, זה שש הנקודות הבאות.

1. קובעים קודם “מה רוצים להשוות” האם רוצים לראות הבדל קוד, או חוויית משתמש אמיתית — הסביבה שצריך לתאם משתנה בהתאם.

2. מתעדים power mode ו-power plan כשני דברים נפרדים ב-Windows, אם מתעלמים כאן ברשלנות, ההשוואה נוטה להפוך להשוואת מדיניות חיסכון בחשמל של מערכת ההפעלה.

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

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

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

6. אם ההבדל קטן, חופרים עד הסיבה עם ETW /‏ WPR אם דנים רק לפי תחושה, שני הצדדים נשארים בלי גיבוי, ומגיעים לקווים מקבילים.

מפת הידע של המאמר

המאמר הזה עוסק ביכולת השחזור בהשוואת מהירות בין גרסאות של תוכנית ב-Windows, ומראה שקיבוע ותיעוד של שתי שכבות הגדרת חשמל — Power mode (overlay) ו-Power plan — הם תנאי בסיס. הבדל ב-Power mode משפיע על התנהגות ה-PPM כמו core parking, ובמכשירים התומכים ב-Modern Standby אפשרויות ה-Power plan עצמן מוגבלות לרוב למשפחת Balanced. תהליכי רקע כמו אינדוקס חיפוש, סריקות Defender והתראות עלולים לגרום לפיזור בערכי המדידה, וניתן להקטין זאת עם הגדרות החרגה, אתחול נקי (clean boot), והשתקת התראות. מומלץ למדוד בנפרד Wall-clock time,‏ CPU time ו-Cycle count באמצעות QueryPerformanceCounter,‏ GetProcessTimes ו-QueryProcessCycleTime בהתאמה, וכאשר ההבדל קטן והסיבה אינה ברורה — לתעד עקבות ETW עם WPR ולהשוות אותם עם WPA.

flowchart LR
    accTitle: מפת הידע של יכולת השחזור בהשוואת benchmark בין גרסאות ב-Windows
    accDescr: תרשים המראה שקיבוע ותיעוד של שתי שכבות הגדרת חשמל, Power mode ו-Power plan, הם תנאי ליכולת שחזור של benchmark, שתהליכי רקע כמו אינדוקס חיפוש וסריקות Defender גורמים לפיזור בערכי המדידה וניתן להקטין זאת עם הגדרות החרגה או אתחול נקי, שמדידת Wall-clock time,‏ CPU time ו-Cycle count נעשית כל אחת עם API ייעודי, ואת תהליך ההעמקה עם WPR ו-WPA כשהפער קטן.
    benchmark_reproducibility["שחזוריות של מדידת ביצועים"]
    power_mode["מצב חשמל / תוכנית חשמל (PPM)"]
    power_plan["‏Power plan (תוכנית חשמל)"]
    powercfg["powercfg"]
    modern_standby["התקנים התומכים ב-Modern Standby"]
    core_parking["Core Parking"]
    search_indexing["בניית אינדקס החיפוש"]
    benchmark_result_variance["פיזור התוצאות במדידת ביצועים"]
    exclusion_setting["הגדרת החרגה (החרגת תיקייה)"]
    clean_boot["אתחול נקי (clean boot)"]
    do_not_disturb["‏Do not disturb (השתקת התראות)"]
    wpr["Windows Performance Recorder(WPR)"]
    etw["ETW(Event Tracing for Windows)"]
    wpa["Windows Performance Analyzer(WPA)"]
    inconclusive_benchmark_result["תוצאת מדידה עם פער קטן או בלתי מוסבר"]
    wall_clock_time["‏Wall-clock time (זמן אמיתי)"]
    queryperformancecounter["QueryPerformanceCounter(QPC)"]
    cpu_time["‏CPU time (זמן משתמש + זמן ליבה)"]
    getprocesstimes["GetProcessTimes"]
    cycle_count["‏Cycle count (מספר מחזורי מעבד)"]
    queryprocesscycletime["QueryProcessCycleTime"]
    process_priority["מחלקת עדיפות (priority class)"]
    start_command["הפקודה start"]
    processor_affinity["זיקת מעבד (affinity mask)"]
    processor_groups["קבוצות מעבדים (Processor Groups)"]
    benchmark_reproducibility -->|"מחייב"| power_mode
    benchmark_reproducibility -->|"מחייב"| power_plan
    power_plan -->|"מוגדר באמצעות"| powercfg
    modern_standby -.->|"אינו מתיישב עם"| power_plan
    core_parking -.->|"מוגדר באמצעות"| power_mode
    search_indexing -.->|"עלול לגרום ל"| benchmark_result_variance
    exclusion_setting -.->|"מצמצם"| benchmark_result_variance
    clean_boot -->|"מצמצם"| benchmark_result_variance
    do_not_disturb -.->|"מצמצם"| benchmark_result_variance
    wpr -->|"משתמש ב"| etw
    wpa -->|"משתמש ב"| etw
    wpa -.->|"מחייב"| wpr
    wpr -->|"מענה מומלץ ל"| inconclusive_benchmark_result
    wall_clock_time -->|"נבדק באמצעות"| queryperformancecounter
    cpu_time -->|"נבדק באמצעות"| getprocesstimes
    cycle_count -->|"נבדק באמצעות"| queryprocesscycletime
    process_priority -->|"מוגדר באמצעות"| start_command
    processor_affinity -->|"מוגדר באמצעות"| start_command
    processor_affinity -.->|"מחייב"| processor_groups
    benchmark_reproducibility -.->|"משתמש ב"| wall_clock_time
    benchmark_reproducibility -.->|"משתמש ב"| cpu_time
    benchmark_reproducibility -.->|"משתמש ב"| cycle_count
    benchmark_result_variance -->|"אינו מתיישב עם"| benchmark_reproducibility
    benchmark_reproducibility -.->|"עלול לגרום ל"| inconclusive_benchmark_result
    benchmark_reproducibility -.->|"משתמש ב"| start_command

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

קודם קובעים מה רוצים להשוות

“השוואת מהירות” נשמעת כמושג אחד, אבל בפועל יש שני סוגים.

1. השוואה שרוצים לראות בה הבדל קוד

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

במקרה הזה, מצמצמים ככל האפשר את רעש הסביבה. פגישת benchmark ייעודית, קיבוע power mode, עצירת התראות, דיכוי אינדקס חיפוש וסנכרון, ואם צריך — גם clean boot.

2. השוואה שרוצים לראות בה חוויית משתמש אמיתית

השוואה שרוצה לדעת את המהירות שהמשתמש חש בפועל ב-Windows הרגיל שלו אחרי ההפצה.

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

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

flowchart TB
    accTitle: לא מערבבים בין שני סוגי ההשוואה
    accDescr: תרשים המראה שבהשוואה שרוצים בה הבדל קוד מצמצמים ככל האפשר רעש סביבה, ובהשוואה שרוצים בה חוויית משתמש אמיתית משאירים רעש מציאותי בסביבה יומיומית, ושעירוב בין השניים מפתל את המסקנה.
    q5["מה רוצים להשוות"] -->|"הבדל קוד"| lab1["סביבת מעבדה בלי רעש"]
    q5 -->|"חוויית משתמש אמיתית"| real1["סביבה יומיומית עם רעש"]
    q5 -.->|"אם מערבבים"| twist2["המסקנה מתפתלת"]

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

הגורם העיקרי לתנודתיות ב-Windows

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

בקיצור, גם “אותו מחשב Windows” הוא ניסוי אחר אם התנאים לא מתואמים.

flowchart TB
    accTitle: בלי תנאים מתואמים זה ניסוי אחר
    accDescr: תרשים המראה שגם כשמודדים על אותו מחשב Windows, אם תנאים רב-שכבתיים מחומרה ועד חשמל, חום, רקע ותנאי build לא מתואמים, זה בפועל ניסוי אחר, ורק תיאום התנאים הופך את זה להשוואה.
    same1["מדידה על אותו מחשב Windows"] -.->|"התנאים לא מתואמים"| oth1["בפועל, ניסוי אחר"]
    same1 -->|"תיאום ותיעוד תנאים רב-שכבתיים"| cmp1["רק אז זו השוואה"]

איור 3: גם כשהמחשב זהה, אם התנאים בין השכבות לא מתואמים, זה לא נחשב השוואה.

מפרידים בין power mode ל-power plan

זו נקודה חשובה מאוד.

ב-Windows קיימים ה-Power mode של אפליקציית ההגדרות, וה-Power plan המסורתי (תוכנית החשמל שרואים ב-powercfg). המראה דומה ולכן נוטים לערבב, אבל טיפול רשלני הופך את ההשוואה לבלגן.

באפליקציית ההגדרות של Windows, אפשר לבחור את ה-Power mode דרך Settings > System > Power & battery. לפי התיעוד של Microsoft, אפשר להחליף בין Best power efficiency,‏ Balanced,‏ Best performance לכל אחד מ-Plugged in /‏ On Battery. בנוסף, כש-Power mode משתנה, זה משפיע גם על ההגדרות הקשורות לחשמל שמאחוריו ועל התנהגות ה-PPM‏ (‏Processor Power Management). כלומר, גם רק הבדל כאן עלול לשנות את מדיניות חניית הליבות והקנה מידה של הביצועים.

מצד שני, Power plan הוא תוכנית חשמל מסורתית כמו Balanced,‏ High performance. אפשר לבדוק עם powercfg /list או powercfg /getactivescheme.

מה שמסבך כאן הוא שב-Windows קיימים גם שכבת-על (overlay) של power mode וגם power plan. אם מציגים את הקשר בציור, זה נראה כך:

flowchart TB
    accTitle: שתי השכבות של power mode ו-power plan
    accDescr: תרשים המראה שאפליקציית ההגדרות שולטת בשכבת-העל של Power mode ו-powercfg שולט בתוכנית החשמל, ששתי השכבות יחד עם ההזנה מ-AC או סוללה קובעות את הגדרת החשמל שבאמת פועלת, שמשפיעה על תקרת התדר, חניית ליבות וקנה מידה של ביצועים.
    subgraph upper["השכבה העליונה: Power mode - שכבת-על"]
        direction LR
        M1["Best power efficiency"]
        M2["Balanced"]
        M3["Best performance"]
    end

    subgraph lower["השכבה התחתונה: Power plan - תוכנית חשמל"]
        direction LR
        P1["Balanced"]
        P2["High performance"]
        P3["custom plan"]
    end

    UI["אפליקציית ההגדרות — Power mode תחת Power and battery"] --> upper
    CLI["מעבר עם powercfg /setactive"] --> lower
    upper --> PPM["ההגדרה שבאמת פועלת — PPM ותת-הקבוצה הגרפית"]
    lower --> PPM
    AC["הזנה מ-AC או מסוללה"] --> PPM
    PPM --> RESULT["תקרת התדר / חניית ליבות / קנה מידה של ביצועים"]

איור 4: שתי השכבות — Power mode (שכבת-על) ו-Power plan — יחד עם AC/DC קובעות את הגדרת החשמל שבאמת פועלת.

לא ניתן לקבוע את ההתנהגות בפועל רק מהשכבה העליונה או רק מהתחתונה. לכן, בתוצאת benchmark, לפחות תעדו:

• האם AC או סוללה
• מהו ה-Power mode
• מהו ה-Active power plan

תוצאת benchmark שלא רשומים בה שלושת אלה, אי אפשר לשחזר את התנאים כשחוזרים אליה מאוחר יותר.

flowchart TB
    accTitle: שלושת הפרטים שתמיד מתעדים
    accDescr: תרשים המראה שאם לא מתעדים יחד עם התוצאה האם זה AC או סוללה, מהו ה-Power mode ומהו ה-Active power plan, לא ניתן לשחזר את התנאים בבדיקה מאוחרת יותר.
    r1["AC או סוללה"] --> rec2["מתועד יחד עם התוצאה"]
    r2["Power mode"] --> rec2
    r3["Active power plan"] --> rec2
    rec2 --> rst1["התנאים ניתנים לשחזור בהמשך"]

איור 5: שלושת הפרטים סביב החשמל הם המינימום שבלעדיו התוצאה בלתי ניתנת לשחזור.

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

1. מחשב נייד תמיד משווים בהזנת AC הפעלה מסוללה נוטה להחיל הגבלה בלתי מכוונת.

2. מקבעים את ה-Power mode לצורך benchmark, מנסים קודם Best performance.

3. מתעדים את ה-Active power plan שומרים עם powercfg את הערך הנוכחי.

powercfg /list
powercfg /getactivescheme

הפלט של powercfg /list מוצג בתיעוד של Microsoft בצורה הבאה. לתוכנית הפעילה מתווסף * בסוף השורה. בסביבה עברית, הכותרת ושם התוכנית יוצגו בשפה המקומית.

Existing Power Schemes (* Active)
-----------------------------------
Power Scheme GUID: {guidPlan1}  (Balanced) *
Power Scheme GUID: {guidPlan2}  (Power saver)

את ה-GUID שהתקבל כאן, מעתיקים ישירות לעמודת power_plan בקובץ התוצאה. הנקודה החשובה היא לתעד GUID ולא שם. גם כש”מאוזן” נראה זהה, ייתכן שזו תוכנית אחרת ששוכפלה או הותאמה אישית.

1. אם צריך, מחליפים ל-High performance

# Balanced
powercfg /setactive 381b4222-f694-41f0-9685-ff5bb260df2e

# High performance
powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

האם אפשר להחליף Power mode עם פקודה

זו נקודה שקל להיתקע בה. ברשימת אפשרויות שורת הפקודה הפרסומית של powercfg, אין אפשרות לבחור מחדש את Power mode (שכבת-העל) עצמו. ההליך הרשמי להחלפה הוא דרך Settings > System > Power & battery באפליקציית ההגדרות.

מצד שני, powercfg תומך בקריאה וכתיבה של ערכי ההגדרה של סכימת שכבת-העל. בתיעוד כתובים הדברים הבאים:

• אם מעבירים ל-powercfg /q את הכינוי (alias) ותת-הקבוצה של שכבת-העל, אפשר לקרוא את ההגדרה שבצד שכבת-העל
• ‏powercfg /setacvalueindex ו-/setdcvalueindex ניתנים לשימוש גם בסכימת שכבת-העל
• אם לא מציינים סכימה, היעד הוא שכבת-העל הפעילה כרגע (ואם אין שכבת-על, תוכנית החשמל הנוכחית)
• אפשר לבדוק את רשימת הכינויים עם powercfg /aliases

כלומר, מה שאפשר לעשות בפקודה הוא “לקרוא ולכוונן את תוכן שכבת-העל הפעילה כרגע”, ולא “לשנות איזו שכבת-על נבחרת”. כנוהל שחזורי ל-benchmark, מעשי יותר לקבע את Power mode ידנית באפליקציית ההגדרות, ולכתוב את הערך בתוצאה. במסמך הנוהל רושמים במפורש “הוגדר Power mode = Best performance”, ובודקים על המסך בכל הרצה.

flowchart TB
    accTitle: מה powercfg יכול ומה לא
    accDescr: תרשים המראה ש-powercfg יכול לקרוא ולכוונן את תוכן שכבת-העל הפעילה, אבל אין אפשרות לשנות איזו שכבת-על נבחרת, ולכן מעשי לקבע את Power mode ידנית באפליקציית ההגדרות ולתעד את הערך.
    pc1["powercfg"] -->|"יכול"| rw1["קריאה וכוונון של תוכן שכבת-העל"]
    pc1 -.->|"לא יכול"| sel1["שינוי איזו שכבת-על נבחרת"]
    sel1 --> hand1["קיבוע ידני באפליקציית ההגדרות ותיעוד"]

איור 6: לא ניתן לשנות בפקודה את בחירת שכבת-העל, ולכן מקבעים ידנית ומתעדים.

“High performance לא מופיע” זה מצב רגיל

גם זו נקודת היתקעות. לפי התיעוד של Microsoft, במכשירים שתומכים ב-Modern Standby, מותרות רק Balanced או תוכניות שנגזרות מ-Balanced. לכן, לא “High performance לא נמצא, זה תקול?”, אלא ייתכן שזה תכנון המכשיר, ככה זה.

בנוסף, Microsoft מנחה ש”אם Power mode לא ניתן לשינוי, ייתכן שנבחרה custom power plan, ולכן כדאי לנסות קודם לבחור Balanced”. כשה-UI של Power mode לא זז, כדאי לחשוד כאן ראשון.

flowchart TB
    accTitle: איך רואים את המקרה שבו High performance לא מופיע
    accDescr: תרשים המראה שבמכשירים שתומכים ב-Modern Standby, רק Balanced או תוכניות שנגזרות ממנו מותרות, ולכן היעדר High performance הוא תכנון, וכש-UI של Power mode לא זז, חושדים ראשון שנבחרה custom plan ומנסים Balanced קודם.
    nohp1["High performance לא נמצא"] --> ms1["אם תומך ב-Modern Standby, זה תכנון"]
    nomv1["ה-UI של Power mode לא זז"] --> cst1["חושדים באפשרות custom plan"]
    cst1 --> bl1["מנסים לבחור קודם Balanced"]

איור 7: היעדר תוכנית או UI שלא זז לא בהכרח תקלה — קודם בודקים את תכנון הדגם ואת בחירת התוכנית.

סותמים רעש רקע

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

קודם מפעילים מחדש וממתינים שיירגע

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

flowchart TB
    accTitle: מפעילים מחדש וממתינים שיירגע
    accDescr: תרשים המראה שאחרי שינוי הגדרה מפעילים מחדש פעם אחת, ומכיוון שמיד אחרי ההפעלה עדכון, אינדקס, סנכרון ו-Defender עדיין פעילים, לא מריצים מיד אחרי הכניסה אלא ממתינים כמה דקות לפני שמתחילים למדוד.
    chg1["שינוי הגדרה"] --> rb1["הפעלה מחדש פעם אחת"]
    rb1 --> wt1["המתנה של כמה דקות אחרי הכניסה"]
    wt1 --> ms2["ורק אז מתחילים למדוד"]
    rb1 -.-> nzz1["מיד אחרי ההפעלה, תהליכים קבועים עדיין פעילים"]

איור 8: מתחילים למדוד רק אחרי שהפעולה ברקע נרגעה, אחרי ההפעלה מחדש.

להשוואה קפדנית, משתמשים ב-clean boot

Microsoft מנחה הליך להגעה להרכב הפעלה מינימלי בעזרת clean boot. בשיטה זו, עוצרים שירותים שאינם של Microsoft עם msconfig, ומבטלים את Startup apps ב-Task Manager.

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

משתיקים התראות

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

מפעילים ידנית Do not disturb, או לפחות מכבים התראות בזמן ה-benchmark.

מדכאים אינדקס חיפוש וסנכרון

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

• מוציאים את תיקיית ה-benchmark מהיעד לאינדוקס
• עוצרים סנכרון של OneDrive /‏ Dropbox /‏ Google Drive וכדומה
• סוגרים דפדפן,‏ Teams,‏ Discord,‏ Slack

זה לא מרשים, אבל כשזה משפיע — זה משפיע מאוד.

flowchart TB
    accTitle: רעש שנוגס ב-benchmark שנוגע בהרבה קבצים
    accDescr: תרשים המראה שב-benchmark מסוג שקורא וכותב הרבה קבצים, אינדקס החיפוש, הסנכרון בענן ואפליקציות קבועות נוגסים במדידה, ולכן החרגה או עצירה מצמצמות רעש.
    ix1["אינדקס חיפוש"] --> hit1["נוגס ב-benchmark שנוגע בהרבה קבצים"]
    sy1["סנכרון ענן"] --> hit1
    ap2["אפליקציות קבועות"] --> hit1
    hit1 --> cutn1["החרגה ועצירה מצמצמות רעש"]

איור 9: ככל ש-benchmark קורא וכותב יותר קבצים, עצירת אינדקס וסנכרון משפיעה יותר.

השוואה בלי לתאם חום, בעצם משווה חום

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

flowchart TB
    accTitle: המנגנון שבו החום משנה את התנאים
    accDescr: תרשים המראה ש-CPU ו-GPU משנים שעון כשהם קרים לעומת אחרי שהתחממו, ולכן גם אותו קוד משתנה בתנאיו בכל הרצה, ושהשוואה בלי לתאם חום בעצם משווה חום.
    cold1["הרצה במצב קר"] --> hot1["ההתחממות משנה את השעון"]
    hot1 --> vary1["התנאים משתנים בכל הרצה"]
    vary1 -.-> heatc1["השוואה בלי תיאום חום משווה חום"]

איור 10: השעון נע לפי החום, ואם לא מתאמים תנאי חום, משווים קירור ולא קוד.

כללים שכדאי לשמור עליהם

• מתאמים ככל האפשר את טמפרטורת החדר
• מקבעים את אופן הצבת המחשב הנייד
• מקבעים את הרכב מתאם ה-AC, המעגן ותצוגות חיצוניות
• לא עושים עבודה כבדה לפני ה-benchmark
• מודדים בנפרד את ההרצה הראשונה ואת המצב היציב

הסדר הריצה — לסירוגין

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

מומלץ אחד מאלה:

• A B A B A B ...
• A B B A A B B A ...
• יוצרים מראש סדר אקראי, ורצים לפיו

flowchart TB
    accTitle: סדר ההרצה משנה איך ההטיה נספגת
    accDescr: תרשים המראה שאם מריצים קודם את כל A ואז את כל B, ההטיה של חום, מטמון ופעילות ברקע נספגת רק בצד אחד, ואילו ריצה לסירוגין או בסדר אקראי מפזרת את ההטיה לשני הצדדים ומסירה את השפעת הסדר מההבדל.
    seq1["כל A → כל B"] --> bias1["ההטיה נספגת רק בצד אחד"]
    alt1["לסירוגין A B A B, או סדר אקראי"] --> even1["ההטיה מתפזרת לשני הצדדים"]
    even1 --> fair1["השפעת הסדר מוסרת מההבדל"]

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

מה שמודדים קובע את המשמעות של “מהיר”

אם דוחסים “מהיר” למספר בודד, בדרך כלל זה נכשל. שלושת המדדים הייצוגיים שכדאי לראות ב-Windows:

1. Wall-clock time (זמן אמיתי)

הזמן שהמשתמש מחכה. זה הקרוב ביותר לחוויית end-to-end, ולכן זה הערך הראשון שבודקים.

ב-Windows, QueryPerformanceCounter‏ (QPC) משמש לקבלת זמן ברזולוציה גבוהה. ב-managed code, בסיסי להשתמש בשרשרת Stopwatch. להסתכל על מילישניות עם DateTime.Now זה קצת חשוף מדי.

2. CPU time (זמן משתמש + זמן ליבה)

הזמן שבו התהליך באמת השתמש ב-CPU, שמתקבל עם GetProcessTimes.

זה נוח לראות יעילות חישוב. לדוגמה, אם wall-clock מהיר יותר אבל CPU time לא השתנה, ייתכן שמטמון, I/O, זמן המתנה או תזמון משפיעים.

3. Cycle count (מספר מחזורי מעבד)

עם QueryProcessCycleTime אפשר לקבל את מספר מחזורי ה-CPU של כל התהליך.

גם זה מדד ל-CPU work, אבל הוא מראה פן אחר מ-wall-clock. נוח במיוחד כשרוצים לראות “האם זמן ההמתנה זהה, אבל חלק החישוב נהיה קל יותר”.

flowchart TB
    accTitle: הפן ששלושת המדדים מראים
    accDescr: תרשים המראה ש-wall-clock time מראה כמה המשתמש מחכה, CPU time מראה כמה CPU התהליך באמת השתמש, ו-cycle count מראה כמה כבד חלק החישוב, ורק בשילוב אפשר לקרוא את התוכן של המהירות.
    spd1["בוחנים את תוכן ה'מהיר'"] --> w1["wall-clock: זמן המתנה"]
    spd1 --> u1["CPU time: זמן CPU בפועל"]
    spd1 --> cy1["cycle: כובד חלק החישוב"]
    w1 -.-> mixr1["מנחשים את הסיבה מהשילוב"]

איור 12: לא דוחסים למספר בודד — קוראים את משמעות המהירות משילוב שלושת המדדים.

priority,‏ affinity,‏ NUMA הם המוצא האחרון

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

קודם מודדים רגיל

אם ההבדל מופיע במצב ברירת מחדל, יש ערך בהבדל הזה כשלעצמו. אם ישר מכניסים /high או /affinity, זה מכניס “תנאי שלא קורה ב-Windows בפועל”.

flowchart TB
    accTitle: priority ו-affinity הם המוצא האחרון
    accDescr: תרשים המראה שקודם מודדים במצב ברירת מחדל, ואם מופיע הבדל יש בו ערך, ושהזרקת עדיפות או affinity ישר מכניסה תנאי שלא קורה בפועל ב-Windows, ולכן אם משתמשים בכך, זה רק בסוף מתוך מטרה מוגדרת.
    def1["קודם מודדים במצב ברירת מחדל"] --> val1["הבדל שמופיע — יש בו ערך"]
    early1["הזרקת /high או /affinity ישר"] -.-> art1["מכניסה תנאי שלא קורה בפועל"]
    val1 -->|"אם צריך, קובעים מטרה"| lastr1["ומקבעים כמוצא אחרון"]

איור 13: עדיפות ו-affinity משמשים אחרי שסיימו מדידה בברירת מחדל, ומתוך מטרה מוגדרת.

אם משתמשים, מבהירים את המטרה

• ‏/high: רוצים לצמצם הפרעה מתהליכים אחרים
• ‏/affinity: רוצים לקבע הקצאת CPU להשוואה
• בקרת NUMA: במחשב גדול, רוצים לתאם גם מיקום זיכרון

הפקודה start של Windows יכולה להפעיל עם ציון priority class ו-affinity mask.

start "" /high /wait myapp.exe --bench case1.json
start "" /affinity F /high /wait myapp.exe --bench case1.json

עם זאת, נמנעים מ-/realtime

/realtime ניתן לשימוש, אבל עדיף לא להשתמש בו. זה נוטה להביא לא לסילוק רעש, אלא ליצירת תקרית אחרת.

נוהל מדידה מומלץ

לאור כל זה, נסכם נוהל שנוח לתפעול בפועל.

נוהל שנוטה למעבדה

1. מקבעים את יעד ההשוואה
   • commit hash / build number
   • גרסת compiler / runtime
   • Debug /‏ Release
   • קיום לוגים, assert, trace
2. מקבעים את תנאי המחשב
   • build של Windows
   • גרסת BIOS /‏ UEFI
   • גרסת driver
   • הזנת AC
   • טמפרטורת חדר, אופן הצבה
3. מקבעים תנאי חשמל
   • קובעים את ה-Power mode
   • מתעדים את ה-Active power plan
4. מפעילים מחדש
5. ממתינים כמה דקות לפני ה-benchmark
6. אם צריך, clean boot
7. מוסיפים warm-up
8. מריצים A /‏ B לסירוגין
9. מבטיחים מספר הרצות
10. שומרים חציון, מינימום, מקסימום,‏ p95
11. שומרים raw data
12. אם ההבדל קטן, לוקחים ETW /‏ WPR

כמה פעמים מריצים

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

זמן הביצוע ניתן לאמוד לפי זמן הרצה בודד × מספר הרצות × מספר גרסאות + warm-up. אם עיבוד של 30 שניות מורץ 30 פעמים לכל אחד מ-A /‏ B, זה מחושב לבערך 35 דקות כולל warm-up. אם זה לא ריאלי, נכון יותר לחתוך את מטרת המדידה לחלק קטן יותר (להוציא רק את השלב הכבד), במקום לצמצם את מספר ההרצות.

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

flowchart TB
    accTitle: מתי עוצרים את מספר ההרצות
    accDescr: תרשים המראה שמגדילים את מספר ההרצות תוך מעקב אחרי מגמת החציון, ועוצרים כשהחציון כבר לא זז גם עם הגדלת המספר - קביעה מעשית למספר הרצות.
    add2["מגדילים את מספר ההרצות"] --> mdz1["עוקבים אחרי מגמת החציון"]
    mdz1 -->|"עדיין זז"| add2
    mdz1 -->|"כבר לא זז גם עם הגדלה"| stop1["עוצרים כאן"]

איור 14: גם בלי לקבע מראש את מספר ההרצות, אפשר לעצור בנקודה שהחציון התייצב.

פרטים ששווה לתעד — יעזרו בהמשך

בקובץ ה-CSV או ה-JSON של ה-benchmark, שווה לשמור לפחות את אלה:

timestamp,version,scenario,elapsed_ms,user_ms,kernel_ms,cycles,power_mode,power_plan,ac_or_dc,room_temp_c,notes

אם אפשר, נוח להוסיף גם:

cpu_package_temp_start_c,cpu_package_temp_end_c,affinity_mask,priority_class,windows_build,driver_version

ל-benchmark, לפעמים היכולת לפרש בהמשך חשובה יותר מעצם המדידה.

מסתכלים לא רק על הממוצע, אלא גם על החציון והפיזור

הממוצע נוח, אבל ב-benchmark על Windows הוא נשבר בקלות. רק חדירה בודדת של Defender, התראה אחת, או תהליך אחר שהכה ב-SSD — והממוצע נגרר.

flowchart TB
    accTitle: הממוצע נגרר על ידי ערך חריג
    accDescr: תרשים המראה שרק רעש בודד של סריקת Defender, התראה או I/O של תהליך אחר גורר את הממוצע, ולכן מתבססים על החציון ומוסיפים p95, p99 ומינימום/מקסימום כדי לקרוא לפי פיזור.
    once3["רעש בודד"] --> avg1["הממוצע נגרר"]
    med2["מתבססים על החציון"] --> dist1["מוסיפים גם p95 / p99 ו-min / max"]
    dist1 --> robust1["קריאה עמידה יותר לערך חריג"]

איור 15: הממוצע נשבר מרעש בודד, ולכן קוראים לפי שילוב חציון ופיזור.

השילוב המומלץ הוא:

• חציון: מסתכלים על זה קודם
• ‏p95 /‏ p99: בודקים אם ה-tail התדרדר
• ‏min /‏ max: בודקים איך זה סוטה
• תרשים קופסה או תרשים פיזור: מועיל כשההבדל קטן

איך קוראים כשמופיע הבדל

הפרשנות של התוצאה קלה יותר כשמסתכלים על שילוב.

מהיר רק ב-wall-clock

ייתכן שיפור ב-I/O, זמן המתנה, מטמון או תזמון.

גם CPU time וגם cycle יורדים

סביר להניח שהמימוש עצמו נעשה קל יותר.

איטי / מהיר רק בפעם הראשונה

זה הבדל cold /‏ warm. חושדים בהפעלה, אתחול, יצירת מטמון,‏ JIT.

נהיה איטי יותר ככל שחוזרים

חושדים בחום, throttling, לחץ זיכרון, פעילות ברקע.

flowchart TB
    accTitle: קוראים את הסיבה מתבנית ההבדל
    accDescr: תרשים המראה שאם ההבדל הוא רק ב-wall-clock חושדים בהמתנה או I/O, אם גם CPU time יורד חושדים במימוש קל יותר, אם ההבדל רק בפעם הראשונה חושדים ב-cold מול warm, ואם ההרצות המאוחרות איטיות יותר חושדים בחום או פעילות רקע.
    pt2["מסתכלים על תבנית ההבדל"] -->|"רק זמן אמיתי"| c1a["המתנה / I/O"]
    pt2 -->|"גם CPU time יורד"| c2a["מימוש קל יותר"]
    pt2 -->|"רק בפעם הראשונה"| c3a["cold / warm"]
    pt2 -->|"איטי בהמשך"| c4a["חום / פעילות רקע"]

איור 16: לא ההבדל עצמו, אלא התבנית שבה הוא מופיע, מכוונת לסיבה.

חופרים עד “למה זה מהיר” עם ETW /‏ WPR

כשההבדל קטן, או שהסיבה לא ברורה, הדרך המלכותית היא להתקדם לכלי ETW‏ (Event Tracing for Windows) של Windows.

‏Windows Performance Recorder‏ (WPR) של Microsoft הוא כלי רישום מבוסס ETW, וכלול ב-Windows ADK. אפשר לרשום יחד CPU,‏ I/O,‏ context switch,‏ page fault ועוד.

ברמה המינימלית, זה נראה כך:

wpr -start CPU -filemode

REM כאן מריצים את ה-benchmark

wpr -stop trace.etl

אחרי פתיחה ב-WPA, הגרפים הראשונים שבודקים בדרך כלל קבועים.

בהשוואה, העיקרון הוא לקחת trace אחד לכל אחד מ-A ו-B, על אותו תרחיש, ולהציג את אותו גרף זה לצד זה. גם עם trace בודד אי אפשר להחליט “האם זה איטי”.

בשלב הזה, אפשר להגיע מ- “‏B מהיר ב-3%” ל- “‏B מקטין המתנה ל-lock וזמן ה-ready יורד” “‏A פותח יותר קבצים ולכן ה-cold start איטי יותר” — לדבר עם סיבה.

flowchart TB
    accTitle: מהבדל מספרי בלבד להבדל עם סיבה
    accDescr: תרשים המראה שכשההבדל קטן או הסיבה לא ברורה, לוקחים עם WPR trace אחד לכל אחד מ-A ו-B על אותו תרחיש, ומשווים ב-WPA את אותו גרף זה לצד זה, ומגיעים לדבר עם סיבה במקום רק אחוז.
    small2["ההבדל קטן / הסיבה לא ברורה"] --> tr1["לוקחים trace ל-A ול-B עם WPR"]
    tr1 --> cmp2["משווים ב-WPA את אותו גרף זה לצד זה"]
    cmp2 --> rsn1["אפשר לדבר עם סיבה"]
    cmp2 -.-> onen1["trace בודד לא מספיק להחליט האם איטי"]

איור 17: כשחופרים עד ETW, “מהיר ב-X%” הופך ל”למה זה מהיר”.

רשימת בדיקה מרוכזת בעמוד אחד

לבסוף, בצורה שאפשר להדביק ישירות למסמך נוהל.

מקבעים

• קיבעתי את יעד ההשוואה (commit hash / build number / Debug או Release / תנאי build כמו PGO / קיום לוגים ו-assert)
• במחשב נייד, חיברתי AC
• קיבעתי את Power mode באפליקציית ההגדרות
• בדקתי את Active power plan עם powercfg /getactivescheme
• עצרתי התראות. עצרתי אינדקס חיפוש וסנכרון בענן
• אם צריך, ביצעתי clean boot
• הפעלתי מחדש, וחיכיתי כמה דקות לפני שהתחלתי

מריצים

• הכנסתי warm-up
• מדדתי בנפרד cold (ראשון) ו-warm (יציב)
• הרצתי A /‏ B לסירוגין, או בסדר אקראי
• קבעתי מספר הרצות והרצתי (ראו את הטבלה למעלה)

מתעדים

• שמרתי raw data של שורה אחת להרצה (‏elapsed_ms /‏ user_ms /‏ kernel_ms /‏ cycles)
• שמרתי AC או DC,‏ Power mode,‏ GUID של ה-power plan, build של Windows, גרסת driver
• שמרתי טמפרטורת חדר ומצב הצבה
• רשמתי גם תנאים שלא קיבעתי

מפרשים

• בדקתי חציון. לא החלטתי לפי ממוצע בלבד
• בדקתי p95 /‏ p99 של ה-tail
• בדקתי min /‏ max לערכים חריגים
• ניחשתי סיבה משילוב wall-clock /‏ CPU time /‏ cycle
• כשההבדל קטן, חפרתי עד ETW /‏ WPR

סיכום

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

• קיבוע ותיעוד של AC /‏ Power mode /‏ power plan
• הפרדה בין cold ל-warm
• הרצה לסירוגין של A /‏ B
• בדיקת חציון ופיזור
• אם צריך, clean boot
• אם ההבדל קטן, חפירה עד הסיבה עם ETW /‏ WPR

והדבר הכי חשוב הוא לכתוב יחד עם התוצאה מה קיבעתי ומה לא קיבעתי. ‏benchmark הוא גם השוואת מהירות, וגם תיעוד תנאי הניסוי.

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

flowchart TB
    accTitle: תיעוד התנאים קובע את ערך התוצאה
    accDescr: תרשים המראה שדוח האצה בלי תנאים נשארים בו רק מספרים ואחרים לא יכולים לוודא, ואילו דוח עם תנאים כתובים כראוי נשארת בו דרך שחזור, כך שגם הבדל קטן שם יש ערך.
    norec1["דיווח בלי תיעוד תנאים"] --> onlyn1["נשארים רק מספרים"]
    onlyn1 --> norep1["אחרים לא יכולים לוודא"]
    rec3["דיווח עם תנאים כתובים"] --> rep1["נשארת דרך שחזור"]
    rep1 --> worth1["גם הבדל קטן — יש ערך"]

איור 18: ערך ה-benchmark טמון פחות במספרים ויותר בתיעוד מה קובע ומה לא נקבע.

מקורות

• Microsoft Support: Change the power mode for your Windows PC
• Microsoft Learn: Power Policy Settings
• Microsoft Learn: Customize the Windows performance power slider
• Microsoft Learn: Powercfg command-line options
• Microsoft Support: How to perform a clean boot in Windows
• Microsoft Support: Notifications and Do Not Disturb in Windows
• Microsoft Support: Search indexing in Windows
• Microsoft Learn: Configure custom exclusions for Microsoft Defender Antivirus
• Microsoft Support: Device Security in the Windows Security App
• Microsoft Learn: QueryPerformanceCounter function
• Microsoft Learn: Acquiring high-resolution time stamps
• Microsoft Learn: GetProcessTimes function
• Microsoft Learn: QueryProcessCycleTime function
• Microsoft Learn: start command
• Microsoft Learn: SetPriorityClass function
• Microsoft Learn: SetProcessAffinityMask function
• Microsoft Learn: Processor Groups
• Microsoft Learn: Windows Performance Recorder
• Microsoft Learn: WPR Command-Line Options
• Microsoft Learn: CPU Analysis in Windows Performance Analyzer - איזה גרף מציג מה.
• Microsoft Learn: Set the Default Power Plan - דוגמת פלט של powercfg -LIST.

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

מה הסיבות העיקריות לתנודתיות בתוצאות benchmark ב-Windows?

יש גורמים בכמה שכבות: מצב חשמל ו-power plan, חום, עדכונים ברקע, אינדקס חיפוש, סריקת אנטי-וירוס, עדיפות ו-affinity, סדר ההרצה, מצב מטמון. גם באותו מחשב Windows, אם התנאים האלה לא מתואמים, זה בפועל ניסוי אחר. בפרט במחשב נייד, ההתנהגות משתנה מאוד בין הזנה מ-AC להזנה מסוללה, ולכן חשוב מאוד להשוות תמיד עם AC ולתעד את התנאים.

מה ההבדל בין power mode ל-power plan?

power mode הוא המעבר בין Best power efficiency,‏ Balanced ו-Best performance שבוחרים ב-Power & battery של אפליקציית ההגדרות, שמשפיע על ההגדרות שמאחוריו וגם על התנהגות ה-PPM‏ (Processor Power Management). power plan הוא תוכנית החשמל המסורתית שבודקים ב-powercfg, כמו Balanced או High performance. ב-Windows קיימים שניהם, ולכן בתוצאת benchmark צריך לתעד לפחות שלושה דברים: האם זה AC או סוללה, מהו ה-power mode, ומהו ה-Active power plan.

האם זה תקלה אם תוכנית החשמל High performance לא מוצגת?

כנראה שזו לא תקלה. לפי התיעוד של Microsoft, במכשירים שתומכים ב-Modern Standby מותרות רק Balanced או תוכניות שנגזרות מ-Balanced. כלומר זה מצב רגיל שבו High performance לא מופיע, לפי תכנון הדגם. בנוסף, אם ה-UI של power mode לא ניתן לשינוי, ייתכן שנבחרה custom power plan, ולכן הכי מהיר לנסות לבחור קודם ב-Balanced.

באיזה סדר כדאי להריץ השוואת מהירות בין גרסה A לגרסה B?

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

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.