דיון בנושא הביצועים בJS
-
-
@אהרן אמר בדיון בנושא הביצועים בJS:
בנוגע ל-PUSH
זה מראה להיפך.תודה רבה רבה! עדכנתי את הפוסט.
היייתה לי טעות פשוטה מאוד בטסט! שמתי את ההכרזה הSetup, ממילא אחרי הדגימה הראשונה המערך הוא כבר בן 1000 איברים, אז ברור שהאינדקס מהיר מהוספה...
עדכנתי כעת את הטסט. הטסט שהבאת מצויין אבל תראה שפעם האינדקס ינצח ופעם הpush, התוצאות שמה נכונות לגירסאות ישנות של כרום. -
@אהרן אמר בדיון בנושא הביצועים בJS:
@dovid
יהיה נוח אם תכניס כאן לינק לדיון פהבנוגע ל:
כשידוע האורך מראש (ובמערכים לא גדולים במיוחד), יש לאתחל את המערך עם Array(length).הטסט הזה מראה שזה משתלם גם בטווח גדול של טעות.
תודה גם לזאת!
כעת בדקתי, והמקרה היחיד בו הייתה עדיפות על Array הייתה במקרה של 100000000 ערכים... מעדכן גם את זה. -
@dovid אמר בדיון בנושא הביצועים בJS:
כעת בדקתי, והמקרה היחיד בו הייתה עדיפות על Array הייתה במקרה של 100000000 ערכים... מעדכן גם את זה.
אתה כנראה מתכוון למקרה ומשתמשים בכל הנו.. התיבות.
אני נסיתי לבדוק האם כדאי להשתמש בקביעות בהערכה גסה.
התשובה היא אולי
ככלל, המקרים שיודיעם בדיוק את אורך המערך הוא אפסי
וכן רוב הדוגמאות הם "דקדוקי עניות"
בדר"כ מדובר בחלקיק מהקוד, וגם בו ההפרש הוא של עשרות אחוזים.חושב שהכי מעניין זה שיטות מבריקות לבניית מילונים\אינדקסים
שם ההפרש יכול להיות בין דקות לחלקיק שניה.דבר נוסף, חשוב מאוד להבין מתי רפרנס מתנהג כמצביע (מחזיק רק כתובת זיכרון), ואיזה פעולות גורמות למשתנה המופנה לעבור לכתובת חדשה ולמצביע להפוך ללא רלוונטי.
-
@אהרן אמר בדיון בנושא הביצועים בJS:
אני נסיתי לבדוק האם כדאי להשתמש בקביעות בהערכה גסה.
ברור שזה כדאי מבחינת מעבד, (זה טיפה עלות מבחינת זיכרון) כמו"כ חובה לשמור את גודל השימוש במשתנה נפרד כי בדקית ריקים היא יקרה.
וכן רוב הדוגמאות הם "דקדוקי עניות"
בדר"כ מדובר בחלקיק מהקוד, וגם בו ההפרש הוא של עשרות אחוזים.יש פה שתי חלקים:
א. יחס בין התוצאות
ב. החלק שלהם בכלל הקוד
היחס דוקא לא קטן, בכל מקום שהוא קטן העלמתי את התובנה.
החלק בקוד הוא לא משנה, כי כל פיסת מהירות הכי קטנה מזרזת את כלל האפליקציה בעוד פרוטה, שדינה כדין מאה.
זה גם מיקל אח"כ למצוא צוארי בקבוק כי ככל שהכל מהר יותר בולט החלקים האיטיים באמת.דבר נוסף, חשוב מאוד להבין מתי רפרנס מתנהג כמצביע (מחזיק רק כתובת זיכרון), ואיזה פעולות גורמות למשתנה המופנה לעבור לכתובת חדשה ולמצביע להפוך ללא רלוונטי.
למה זה כה מורכב? כל ערך פרימיטיבי = לא אובייקט (number, string, bool), מועבר כעותק. כל אובייקט (שזה כולל פונקציה ומערך שכן הם גם אובייקטים) מועברים כמצביע.
-
@dovid אמר בדיון בנושא הביצועים בJS:
ברור שזה כדאי מבחינת מעבד, (זה טיפה עלות מבחינת זיכרון) כמו"כ חובה לשמור את גודל השימוש במשתנה נפרד כי בדקית ריקים היא יקרה.
לא התייחסת למה שכתבתי
דברתי על מקרה בו בדר"כ לא יודעים את אורך המערך, רק הערכה גסה עם טווח רחב של טעויות.
ככל שהטעות גדולה יותר, היעילות קטנה יותר. השאלה מהו הממוצע. להערתי לא משהו.
אא"ט, בבניית מערכים אצלי זה בדר"כ או מאוד קטן, או ע"י split.
אתה מוכן לשלם בחישובים בשביל לחשב את אורך המערך הצפוי בשביל לחסוך ביצירתו?@dovid אמר בדיון בנושא הביצועים בJS:
יש פה שתי חלקים:
אהממ..
אני גדלתי על ימי הדוס וה-XT, שבשביל להצליח לעבוד על כמויות גדולות של דאטה היו צריכים להשתמש בכל השמיניות שרק עלו על הדעת.
מוכרח להודות שתהליך הגמילה קשה, אבל משתלם ונכון
כמו שדין פרוטה כדין מאה, יש גם מושג של דקדוקי עניות.@dovid אמר בדיון בנושא הביצועים בJS:
למה זה כה מורכב? כל ערך פרימיטיבי = לא אובייקט (number, string, bool), מועבר כעותק. כל אובייקט (שזה כולל פונקציה ומערך שכן הם גם אובייקטים) מועברים כמצביע.
ומה קורה אם אתה מתאחל את האוביקט, מגדיל את המערך ע"י concat (הגיוני לרצות לחסוך לולאה)?
-
@אהרן אמר בדיון בנושא הביצועים בJS:
לא התייחסת למה שכתבתי
דברתי על מקרה בו בדר"כ לא יודעים את אורך המערך, רק הערכה גסה עם טווח רחב של טעויות.
ככל שהטעות גדולה יותר, היעילות קטנה יותר. השאלה מהו הממוצע. להערתי לא משהו.
אא"ט, בבניית מערכים אצלי זה בדר"כ או מאוד קטן, או ע"י split.
אתה מוכן לשלם בחישובים בשביל לחשב את אורך המערך הצפוי בשביל לחסוך ביצירתו?התייחסתי בדיוק למה שכתבת. גם עם הטעות ענקית זה יהיה מהר יותר, רק יבזבז זיכרון.
כמו שדין פרוטה כדין מאה, יש גם מושג של דקדוקי עניות.
נבון, אם זה לא הרגל לא שווה להתאמץ לחשוב על זה.
ומה קורה אם אתה מתאחל את האוביקט, מגדיל את המערך ע"י concat (הגיוני לרצות לחסוך לולאה)?
כל פעם שאתה עושה = למשתנה, תוכנו מחלף לחלוטין בין אם הוא מצביע בין אם הוא ערך.
השאלה עם contact לא הבנתי. -
@dovid אמר בדיון בנושא הביצועים בJS:
התייחסתי בדיוק למה שכתבת. גם עם הטעות ענקית זה יהיה מהר יותר, רק יבזבז זיכרון.
@dovid אמר בדיון בנושא הביצועים בJS:
כל פעם שאתה עושה = למשתנה, תוכנו מחלף לחלוטין בין אם הוא מצביע בין אם הוא ערך.
השאלה עם contact לא הבנתי.נכון, ההוספה היא שאם עושים = למשתנה המוצבע, המצביע כבר לא רלוונטי.
var arr = [] var obj = {} / or newArr obj.arr = arr arr.push('hi') obj.arr[0] == 'hi' -- arr = ['test'] obj.arr[0] != 'test' אותו דבר arr.contact(nreArr) obj.arr[0] != 'test'@dovid אמר בדיון בנושא הביצועים בJS:
דחיפת איברים חדשים מהירה יותר במערך (טסט).
הטסט מפנה לטסט obj vs arr insertion.
@dovid אמר בדיון בנושא הביצועים בJS:
תודה רבה רבה! עדכנתי את הפוסט.
עדיין כתוב שזה מהיר יותר.
-
כאן יש דיון מרתק על שימוש מאסיווי ב-CPU בנוד (זה מרתק כי לא הבנתי שם מילה).
וכמו שכתוב שם כאן יש השוואה בין שיתוף פרוססים לשיתוף תהליכים.
מישהו ניסה א"ז?
דבר נוסף קראתי איפשהו לא מזמן (לא מוצא עכשיו)
שבקוד שמשתמש בעיקרו רק ב-CPU (ובפועל סינכרוני) לא נכון להשתמש בפרומיס. יש לכם תובנות? אשמח לכל הרחבה. -
קוד שמשתמש בCPU באופן משמעותי, עדיף שפשוט לא יהיה.
בnodejs הכל רץ בתהליך אחד, וזה אומר שאם הקוד צורך CPU אז כל הקוד עוצר - אין שום תורנות בין קריאות פונקציה לשימוש במעבד - הכל לפי הסדר. כל הפואנטה של nodejs זה תורנות בפעולות I\O שזה אומר שפונקציה לא ממתינה לאחרת כאשר סיבת העיכוב היא דיסק, רשת וכדומה. אם הפעולה היא עיבוד, אז המציאות היא שליבת מעבד יכולה לעשות רק פעולה אחת בזמן נתון.
לכן בפעולות CPU כבדות משתמשים או בWorkers או בFork, שזה אומר להרים תהליך nodejs נפרד כך שתהיה תורנות ברמת מערכת ההפעלה בין התהליכים - וממילא בין קריאות פונקציה של תהליך אחד לאחר.Promise זה לא איזה מנגנון קוסמי זה סה"כ עטיפה לקאלבק הישן והרע. ממילא לדעתי אין לו שום כללים משלו.
Generators אני לא יודע מה הם קשורים לנושא של מקביליות. את fiber אני לא מכיר כלל.
-
@dovid אמר בדיון בנושא הביצועים בJS:
לכן בפעולות CPU כבדות משתמשים או בWorkers או בFork, שזה אומר להרים תהליך nodejs נפרד כך שתהיה תורנות ברמת מערכת ההפעלה בין התהליכים - וממילא בין קריאות פונקציה של תהליך אחד לאחר.
איפה יש דוגמאות קוד נירחבות יותר?
