ביצועי יישומים

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

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

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

אז קדימה ולהשתמש בשפת תכנות אלגנטית כמו Python3 או יבאסקריפט/כתב סוגים, ולתת למומחי הנושא (SME) שם בחוץ בעולם הקוד הפתוח לתת לך עוצמה ג'/C+++

אפילו סקריפט קש נטול תלות הוא פתרון מעשי עבור משימות בסיסיות רבות. הנה אחד שכתבתי לחברת Augmented Reality קפיצת קסם לפני כמה שנים, להחליף את החרדים OpenGrok שירות עם משהו שממנף מקבילות מרובות מעבדים עם xargs - זכאים, ותומך חשבון שותפים חיפוש פשוט אמקס/וים

https://github.com/joesuf4/home/blob/wsl/bin/pffxg.sh

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

הוא גם משתמש בקהילת הקוד הפתוח של SME‘s בצורה חכמה, במקום בדרך שבה מימושים אחרים של “צמחייה רקורסיבית מסוננת” ב-GitHub עשו זאת. במקום לאמץ באופן פנימי ולשמור על יישום משלי (הליכי משנה) של חיפוש, סרגלים, וגם ירוקcolor, אני פשוט עושה שימוש חוזר בקובצי ההפעלה המותקנים מראש שSME‘s מתאימים במיוחד במשך עשרות שנים כפי שהם. אני לא צריך לשלוט ביישום שלהם, רק לעשות שימוש חוזר שלהם. ממשק לקוח

כדי לראות את ההתמודדות ההפוכה, שבה הכל נעשה בתוך הבית, ממוטב לחלוטין, ועדיין לא ניתן לנצח את התסריט הזה עם אפשרויות חיפוש ברירת המחדל, ואין מערכת כתיבה למטמון זמינה, הנה דוגמה מצוינת https://github.com/BurntSushi/ripgrep

רק כדי למשוך את #performance #benchmark הראשון מדף זה, ולהגדיל אותו מגודל עץ מדגם צעצוע (מקורות ליבה לינוקס), לעץ הטרוגני כי הוא 23GB(הריצות הטובות ביותר לאחר 3 חזרות; שפה=en_US.UTF-8

    % du -sh .
    23G .
    % time rg -uuniw '[A-Z]+_SUSPEND' | wc -l
    6259
    rg -uuniw '[A-Z]+_SUSPEND' 9.46s user 16.08s system 261% cpu 9.759 total
    wc -l 0.00s user 0.07s system 0% cpu 9.759 total
    % time pffxg.sh -- -wnE '[A-Z]+_SUSPEND' | wc -l
    5855
    pffxg.sh -- -wnE '[A-Z]+_SUSPEND' 16.66s user 2.68s system 429% cpu 4.501 total
    wc -l 0.00s user 0.00s system 0% cpu 4.501 total

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

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

הסר את #performance #benchmark השני מדף זה, והגדל אותו כמו קודם (אותו הדבר) 23GB

    % time rg -tc -uuuiwn '[A-Z]+_SUSPEND' | wc -l
    5629
    rg -tc -uuuiwn '[A-Z]+_SUSPEND' 3.51s user 1.71s system 1141% cpu 0.457 total
    wc -l 0.00s user 0.05s system 11% cpu 0.457 total
    % time LANG=C pffxg.sh --cache /tmp/pffxg-$USER --workers 32 --cc -- -wE '[A-Z]+_SUSPEND' | wc -l
    5628
    LANG=C pffxg.sh --cache /tmp/pffxg-$USER --workers 32 --cc -- -wE  3.14s user 0.88s system 1055% cpu 0.381 total
    wc -l 0.00s user 0.00s system 0% cpu 0.381 total

מכוונן pffxg.sh הוא עדיין מהיר יותר, למרות כל העבודה שהוכנסה microoptimizing ripgrep עבור זה ג'

הדרך בה השתמשתי בתסריט הזה AOSP (חברה) היה צריך לתזמן a הסכם רכש חוזר סנכרון ואח”כ pffxg.sh **לוזופ-זרע למטמון דחוס אלטמפסים* לרוץ כל בוקר לפני העבודה (דרך) קרונטאב), עם PFFXG_CACHE=... הגדר ב-My ~/.pffxg.conf קובץ. כך כל pffxg.sh הפעלות שהפעלתי במהלך יום העבודה ישתמשו במטמון הדחוס ב טמפסים

25M LOC בין ripgrep וגם ugrep632 LOC עבור pffxg.sh

כי זו תוכנית קטנה כל כך, pffxg.sh יכול לתת לך ווים חזקים לתוך הפנים שלה עם כמעט אפס מאמץ. אפילו את ירוקcolor הפקודה עצמה ניתנת להתאמה אישית: כל פקודה שאתה צריך להריץ על corpus נבחר של קבצים, שיכול לקבל רשימה של שמות קבצים המצורפים לסוף הטיעונים שלה, הוא משחק הוגן. הנה “ספירת שורות כוללת ב MiLOC

    % time find * -type f | xargs wc -l | awk '{ $2 == "total" {a+=$1} END {print a/1024**2}'
    28.451
    find * -type f 0.00s user 0.06s system 2% cpu 2.733 total
    xargs wc -l 0.53s user 1.02s system 54% cpu 2.853 total
    awk '$2 == "total" {a+=$1} END {print a/1024**2}' 0.23s user 0.59s system 28% cpu 2.853 total

    % time pffxg.sh --workers 8 --cmd wc --all -- -l | awk '{$2 == "total" {a+=$1} END {print a/1024**2}'
    28.4506
    pffxg.sh --workers 8 --cmd wc --all -- -l 0.92s user 0.66s system 826% cpu 0.192 total
    awk '$2 == "total" {a+=$1} END {print a/1024**2}' 0.02s user 0.00s system 11% cpu 0.192 total

ripgrep

    % time rg -c \$ | awk -F : '{a+=$2} END {print a/1024**2}'
    28.4284
    rg -c \$ 2.12s user 2.19s system 276% cpu 1.564 total
    awk -F : '{a+=$2} END {print a/1024**2}' 0.58s user 0.45s system 66% cpu 1.564 total

כאן הוא מוגבל ל ג'

    % time pffxg.sh --workers 8 --cc --cmd wc -- -l | awk '$2 == "total" {a+=$1} END {print a/1024**2}'
    25.3935
    pffxg.sh --workers 8 --cc --cmd wc -- -l 0.76s user 0.54s system 734% cpu 0.177 total
    awk '$2 == "total" {a+=$1} END {print a/1024**2}' 0.02s user 0.00s system 9% cpu 0.177 total

וגם ripgrep

    % time rg -tc -c \$ | awk -F : '{a+=$2} END {print a/1024**2}'
    25.3844
    rg -tc -c \$ 3.49s user 1.54s system 441% cpu 1.140 total
    awk -F : '{a+=$2} END {print a/1024**2}' 0.38s user 0.38s system 66% cpu 1.140 total

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

pffxg.sh זה לא מוצר, וזה לא מכירות. “זו דוגמה” כדי להמחיש את הנקודה שלי בצורה דרמטית מאוד. אם אתה מכיר את ההיסטוריה הארוכה של פתרונות מסוננים-רקורסיביים-grep על GitHub, כולם מבוססים על הרעיון כי הבעיה עם המקורי של אנדי לסטר פרל מימוש חשבוןאם זה נכתב ב פרל. . הבעיה האמיתית היחידה מבחינת הביצועים היא פרל נכתב על ידי אנדי, שלא נראה שיש לו שום כישרון למושגים של ביצועי מערכות (כמו חקלאות). חיפוש עבודה במקביל לבנייה ייעודית ג' בִּינָרִי), אבל במקום זאת מכוון לניידות עצלה על ידי ניסיון ללכוד את כל הקוד כטהור בעל הליך משנה יחיד. פרל

מי ייתן ואלף פרחים יפרחו, לא משנה מה הם נראים!