בעת שימוש בתוסף Immersive Translate עם LLM לתרגום אתרים מסוימים, התגלתה תקיעה בעכבר — כמה הצעות של LLM

[AIYA.DE5.NET]

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

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

1. הכנסת ארכיטקטורת עיבוד אסינכרוני (Web Workers)
   נכון לעכשיו, ייתכן שכמות גדולה של התאמות רגולריות (regex), ניתוח HTML והשוואת טקסט מתורגם מתבצעת כולה ב- Content Script (ה-thread הראשי).

• פתרון אופטימיזציה: להעביר ל- Web Worker את הלוגיקה שאינה כוללת פעולות DOM ישירות (כגון ניתוח פרוטוקול סטרימינג של LLM, קדם-עיבוד טקסט, אלגוריתמים להשוואת רב-לשוניות).
• השפעה: שחרור ה-thread הראשי, כדי להבטיח שהדפדפן ימשיך להגיב בגלילת עכבר ולחיצות ב-60fps גם תוך כדי עיבוד נתוני התרגום.

2. יישום “אצוות רינדור” ו“חלוקת זמן” (Scheduling)
   בסטרימינג (Streaming) הדבר שהכי צריך להימנע ממנו הוא לעדכן את ה-DOM בכל תו שמתקבל.

• פתרון אופטימיזציה:
  • עדכון עם חציצה (Buffering): להגדיר buffer של 100ms-200ms, למזג כמה מקטעים שמוחזרים מה-LLM, ואז להפעיל עדכון DOM אחד באמצעות requestAnimationFrame.
  • חלוקת זמן (Time Slicing): אם צריך להוסיף בבת אחת הרבה צמתי תרגום, להשתמש ברעיון דומה ל- React Fiber, לפרק את המשימה למספר משימות קטנות, ולהכניס אותן אחת-אחת כשהדפדפן פנוי (requestIdleCallback).
• השפעה: להפוך Reflow צפוף לעדכונים קצביים, ולהפחית משמעותית עומס רגעי על ה-CPU.

3. “רינדור עצל” מבוסס Viewport (Intersection Observer)
   אם הדף ארוך מאוד, תרגום מלא יגרום לאלפי צמתי DOM להתעדכן ברקע בו-זמנית, גם אם הם לא נמצאים על המסך.

• פתרון אופטימיזציה: להשתמש ב- IntersectionObserver API.
  • רק כשהצומת של הטקסט המקורי נכנס ל-viewport (או עומד להיכנס), להפעיל בקשת תרגום ולחבר את ה-DOM של התרגום.
  • עבור צמתי תרגום שמתרחקים משמעותית מה-viewport, אפשר לשקול להשמיד זמנית או להסתיר, כדי להפחית את לחץ חישובי ה-layout בדפדפן.
• השפעה: הורדת כמות החישוב מ“קנה מידה של כל הדף” ל“קנה מידה של המסך”.

4. אופטימיזציה של אסטרטגיית חיבור ל-DOM (Containment)
   בעת הוספת צמתי תרגום, אם שוברים את ה-layout המקורי, זה עלול לגרום ל-Reflow של כל העמוד.

• פתרון אופטימיזציה:
  • CSS Containment: להוסיף לקונטיינר המתורגם contain: layout; או contain:
    content; . זה מאותת לדפדפן שהשינויים הפנימיים בצומת לא ישפיעו על ה-layout החיצוני.
  • שמירת מקום קבוע: לפני תחילת התרגום, להעריך גובה לפי אורך הטקסט המקורי ולהציב placeholder, כדי למנוע “קפיצות” בזמן שהטקסט המתורגם מגיע בסטרימינג וגורם לעמוד “להתנדנד” שוב ושוב.
• השפעה: הגבלת תחום ה-Reflow, כדי למנוע מצב של “משיכת שערה שמזיזה את כל הגוף”.

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

• פתרון אופטימיזציה:
  • בעת הוספת צמתי תרגום על ידי התוסף, להשתמש בדגל גלובלי (Flag) כדי לחסום זמנית האזנה, או במסנן בתוך ה-listener באמצעות node.isTrusted
    או תכונה ייעודית כדי לסנן צמתים שנוצרו על ידי התוסף עצמו.
  • להגדיל דינמית את סף mutationChangeDelay: כאשר מזהים שהמשתמש גולל במהירות גבוהה, להגדיל אוטומטית את ההשהיה או להשהות את הסריקה.

6. “עדכון אינקרמנטלי” בסטרימינג במקום “החלפה מלאה”

• פתרון אופטימיזציה: אם צומת התרגום הוא קונטיינר, בעדכון סטרימינג יש רק להוסיף (append) צומת טקסט, ולא בכל פעם לבצע innerHTML = …
  ולבנות מחדש את המבנה הפנימי.
• השפעה: הפחתת לחץ על איסוף אשפה (GC) ועלות

[AIYA.DE5.NET]

בעת הפעלת תרגום LLM העומס על ה-CPU קופץ מיד מ-5 ל-50