פיירפוקס זליגת זיכרון רצינית - תוכנה - HWzone פורומים
עבור לתוכן
  • צור חשבון

פיירפוקס זליגת זיכרון רצינית


nat64x

Recommended Posts

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

במציאות של היום (לא משנה איזה יש לך), כל אתר מוצג משתמש בהמון זיכרון. תוסיף לזה את הזיכרון הנחוץ בשביל ההיסטוריה (ופיירופקס גם זוכר טאבים שנסגרו - כמו שהם - בשביל שחזור טאבים Ctrl+Shift+T) ויש לך חגיגה של צריכת זיכרון.

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

אם אתה רוצה לראות אם אכן מדובר בזליגת ולא סתם שימוש סביר, תפתח about:memory ותלחץ על הכפתורים שלמטה (GC/CC/Minimize Memory Usage) ותראה אם הזיכרון התפוס קטן משמעותית (זה אמור לשחרר שזלג, אם אכן היתה זליגה תראה הבדל).

ובלי קשר, למה לא לעדכן ל FF10?

קישור לתוכן
שתף באתרים אחרים

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

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

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

קישור לתוכן
שתף באתרים אחרים

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

ניסית להיכנס לabout:memory ולעשות GC כמו שאמרתי? בדקת את ההבדל אז? (זה אמור לנקות הכל, כל זליגה וזיכרון מיותר שלא באמת בשימוש).

זה למה אין לי בעיה עם כרום (בערך חצי מפיירפוקס בצריכה).

התסכלת שוב על התמונה שהבאת? ראית כמה כרום צורך שם בסך הכל? הוא צורך אותו דבר. (אם אתה חושב שלא, תסביר לי איפה אני טועה).

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

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

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

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

קישור לתוכן
שתף באתרים אחרים

טוב שייט... חיברתי את המספרים.

כרום לוקח 50 תהליכים וצורך בערך 4 ג'יגה LOL

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

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

קישור לתוכן
שתף באתרים אחרים

  • 3 שבועות מאוחר יותר...

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

התקנתי אבל SpeedyFox וזה הוריד את צריכת הזיכרון ל-12 מגה! אני צריך עדיין לבדוק אם הבעיה נפתרה אך אני כרגע משתמש בעיקר בכרום לכן לא עידכנתי.

לומרות מה ש yonizaf אמר אני לא רואה שום סיבה למה דפדפן צריך 3GB של בעוד שדף HTML הוא רק כמה מאות KB.

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

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

קישור לתוכן
שתף באתרים אחרים

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

זה בסך הכל מראה שכנראה לא מדובר בזליגת זיכרון (במובן המקובל) אלא בצריכת זיכרון אמיתית. למה בדיוק? בדף המדובר יש פירוט, אם בא לך לנסות להבין, או אם אתה משועמם מספיק כדי לנסות לשים פה את הטקסט (מ about:memory) כי מעניין אותי להציץ עליו.

התקנתי אבל SpeedyFox וזה הוריד את צריכת הזיכרון ל-12 מגה!

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

לומרות מה ש yonizaf אמר אני לא רואה שום סיבה למה דפדפן אינטרנט צריך 3GB של זיכרון בעוד שדף HTML הוא רק כמה מאות KB.

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

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

(סתם דוגמה תיאורטית מומצאת: נגיד שג'ימייל בודק הודעות חדשות פעם בדקה, ונגיד שבכל פעם כזאת הוא יוצר משתנה בגודל 150KB שלעולם לא נמחק. אחרי 12 שעות יהיה לך בזיכרון 100MB של מידע מיותר בJS, חוץ ממה שהאתר לוקח בלי קשר.)

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

שמשתנה כל הזמן,

קישור לתוכן
שתף באתרים אחרים

זה בסך הכל מראה שכנראה לא מדובר בזליגת זיכרון (במובן המקובל) אלא בצריכת זיכרון אמיתית. למה בדיוק? בדף המדובר יש פירוט, אם בא לך לנסות להבין, או אם אתה משועמם מספיק כדי לנסות לשים פה את הטקסט (מ about:memory) כי מעניין אותי להציץ עליו.

אני לא חושף מידע פרטי על שימושי גלישה. סורי.

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

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

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

אתה צודק. בהתסכלות ב about:memory פיירפוקס מדווח שאתר HWZONE הוא זללן לא קטן של ומוביל עם 70 מגה ברשימה (כנראה בגלל שפתוחים לי מספר טאבים שלו והוא מאגד אותם), פיסבוק 40 מגה (לא בטוח למה זה מתייחס האתר בכלל לא פתוח אצלי), אתרים אחרים 20 מגה ופחות, IMDB לוקח 5 מגה. אני אנבור ברשימה יותר בעיון מאוחר יותר, אם אני אמצע משהו מעניין אני יביא אותו.

קישור לתוכן
שתף באתרים אחרים

v10.0.0.2

אילצתי פתיחה של 200 טאביים או יותר כדי לבדוק את ההבדל.

mir7a.jpg

24xi6ut.jpg

תמונה ראשונה בלי foxboost תמונה שניה עם, יש רק 4 פלגינים פעילים. יש לשים לב שהשימוש הכולל בזיכרון לא השתנה, לכן אני לא רואה במה התוכנה באמת עוזרת. לא חשתי שיפור במהירות, אז כנראה אני יסיר את זה בהמשך. plugin container for גם לוקח עכשיו הרבה .

Other Measurements
0.08 MB -- canvas-2d--bytes
0.00 MB -- gfx-d2d-surfacecache
0.00 MB -- gfx-d2d-surfacevram
0.01 MB -- gfx--image
35.93 MB -- gfx--win32
1,830.36 MB -- heap-allocated
1,868.82 MB -- heap-committed
2.05% -- heap-committed-unallocated-fraction
1.59 MB -- heap-dirty
54.64 MB -- heap-unallocated
2 -- js-compartments-system
232 -- js-compartments-user
948.00 MB -- js-gc-heap
43.42 MB -- js-gc-heap-arena-unused
0.00 MB -- js-gc-heap-chunk-clean-unused
1.63 MB -- js-gc-heap-chunk-dirty-unused
0.00 MB -- js-gc-heap-decommitted
4.75% -- js-gc-heap-unused-fraction
41.88 MB -- js-total-analysis-temporary
203.16 MB -- js-total-mjit
501.19 MB -- js-total-objects
431.92 MB -- js-total-scripts
332.23 MB -- js-total-shapes
42.91 MB -- js-total-strings
87.17 MB -- js-total-type-inference
3,084.58 MB -- private
3,050.86 MB -- resident
3,370.80 MB -- vsize

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

קישור לתוכן
שתף באתרים אחרים

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

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

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

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

קישור לתוכן
שתף באתרים אחרים

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

כן לדיסק. אם אני עושה ריפרש קשה (עם שיפט) לאתר HWZONE שהוא אתר כבד יחסית ואיטי, לוקח לאתר להטען רק 3 שניות (וזה עם הורדת הקבצים מחדש). כמו שאמרתי בעריכה אני מאמין שה- TRADE OFF יהיה לטובת מהירות תצוגה ממספר טאבים מסויים והלאה. 3GB של זה פשוט מטופש להחזיק כשאני צריך רק כ-5MB בפועל כדי להציג את הדף שאני רואה באותו הרגע.

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

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

קישור לתוכן
שתף באתרים אחרים

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

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

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

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

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

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

קישור לתוכן
שתף באתרים אחרים

וכי איך ידע הדפדפן אם קוד הJS שרוצה לרוץ עכשיו משמש לקבלת ההודעה שכל כך חיכית לה בפייסבוק, או סתם להחליף פרסומת שלא אכפת לך ממנה?

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

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

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

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

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

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

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

אם אף אחד עוד לא עשה את זה, כנראה שלאף אחד לא באמת אכפת?

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

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

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

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

קישור לתוכן
שתף באתרים אחרים

ארכיון

דיון זה הועבר לארכיון ולא ניתן להוסיף בו תגובות חדשות.

×
  • צור חדש...