הצעת ייעול | אינדוקס ספרים אישיים איטי
-
לכל המנצחים על המלאכה ייש"כ אדיר על שדרוג האינדוקס המהיר ב996 זה ממש גיוואלדיג, לא יודע למה זה קשור אבל אינדוקס ספרים אישיים מאוד איטי
וא"ת אולי זה לע ערוך טוב י"ל שזה כולל כמובן גם את התוסף ספרים של @יאיר-דניאל שהם ספרים כמו של אוצריא
-
לכל המנצחים על המלאכה ייש"כ אדיר על שדרוג האינדוקס המהיר ב996 זה ממש גיוואלדיג, לא יודע למה זה קשור אבל אינדוקס ספרים אישיים מאוד איטי
וא"ת אולי זה לע ערוך טוב י"ל שזה כולל כמובן גם את התוסף ספרים של @יאיר-דניאל שהם ספרים כמו של אוצריא
זה לא קשור לאינדוקס המהיר של 0.9.96 — מדובר בשני מסלולי קוד שונים.
מה כן משותף: אינדוקס ספר טקסט אישי עובר באותו
_indexTextBookכמו ספרי הספרייה, כולל השיפור המרכזי של 996 — קריאת התוכן כבייטים גולמיים מה-DB והעברתו למנוע בקריאת FFI אחת, בלי פענוח ל-String וקידוד חוזר על הגשר. ספרים אישיים ב-user_books.dbנהנים מזה.מה לא משותף: השדרוגים סביבו יושבים ב-
indexAllBooks, המסלול של אינדוקס הספרייה כולה:- מצב bulk (
setBulkIndexing) — מכבה מיזוגי סגמנטים ברקע תוך כדי הבנייה, וה-optimize בסוף ממזג ממילא. - דחיפת ספרי PDF לסוף התור.
הוספת ספרים אישיים רצה ב-
indexBooks— מסלול נפרד שמאנדקס רק את החדשים, ואינו מפעיל את מצב ה-bulk כלל. כלומר אותו מנוע, בלי האופטימיזציה. זו בדיוק ההצעה שאתה מחפש, והיא נראית שינוי קטן יחסית.שאלה שתחדד את התמונה: הספרים האישיים שלך הם PDF או TXT/DOCX? חילוץ טקסט מ-PDF עובר דרך pdfium ב-worker isolate יחיד ומסורל לחלוטין — איטי בסדר גודל מאינדוקס ספר טקסט. אם אלה PDF, זה כנראה רוב הפער ולא מצב ה-bulk.
בהקשר הזה: בענף dev (אחרי 996, לא בגרסה שבידך) נוסף תור חילוץ PDF מקדים בעומק 25 סלוטים כדי שה-worker לא יישב בטל בין ספר לספר. גם הוא נמצא רק במסלול האינדוקס המלא.
ההצעה שווה מעקב — כדאי לפתוח issue: https://github.com/Otzaria/otzaria/issues
- מצב bulk (
-
זה לא קשור לאינדוקס המהיר של 0.9.96 — מדובר בשני מסלולי קוד שונים.
מה כן משותף: אינדוקס ספר טקסט אישי עובר באותו
_indexTextBookכמו ספרי הספרייה, כולל השיפור המרכזי של 996 — קריאת התוכן כבייטים גולמיים מה-DB והעברתו למנוע בקריאת FFI אחת, בלי פענוח ל-String וקידוד חוזר על הגשר. ספרים אישיים ב-user_books.dbנהנים מזה.מה לא משותף: השדרוגים סביבו יושבים ב-
indexAllBooks, המסלול של אינדוקס הספרייה כולה:- מצב bulk (
setBulkIndexing) — מכבה מיזוגי סגמנטים ברקע תוך כדי הבנייה, וה-optimize בסוף ממזג ממילא. - דחיפת ספרי PDF לסוף התור.
הוספת ספרים אישיים רצה ב-
indexBooks— מסלול נפרד שמאנדקס רק את החדשים, ואינו מפעיל את מצב ה-bulk כלל. כלומר אותו מנוע, בלי האופטימיזציה. זו בדיוק ההצעה שאתה מחפש, והיא נראית שינוי קטן יחסית.שאלה שתחדד את התמונה: הספרים האישיים שלך הם PDF או TXT/DOCX? חילוץ טקסט מ-PDF עובר דרך pdfium ב-worker isolate יחיד ומסורל לחלוטין — איטי בסדר גודל מאינדוקס ספר טקסט. אם אלה PDF, זה כנראה רוב הפער ולא מצב ה-bulk.
בהקשר הזה: בענף dev (אחרי 996, לא בגרסה שבידך) נוסף תור חילוץ PDF מקדים בעומק 25 סלוטים כדי שה-worker לא יישב בטל בין ספר לספר. גם הוא נמצא רק במסלול האינדוקס המלא.
ההצעה שווה מעקב — כדאי לפתוח issue: https://github.com/Otzaria/otzaria/issues
@Otzaria-Bot ציינתי בספויילר שזה גם לתוסף של יאיר-דניאל 'הורדת ספרים' שזה קבצי טקסט, וזה לא כזה משנה לי למה זה קשור, אני לא מתכנת אני רק מדווח על בעיה
- מצב bulk (
-
@Otzaria-Bot ציינתי בספויילר שזה גם לתוסף של יאיר-דניאל 'הורדת ספרים' שזה קבצי טקסט, וזה לא כזה משנה לי למה זה קשור, אני לא מתכנת אני רק מדווח על בעיה
אם אלה קבצי טקסט, אז ההסבר על PDF לא רלוונטי כאן — והפער כולו הוא מצב ה-bulk. אימתתי בקוד (
lib/indexing/repository/indexing_repository.dart, ענף dev):indexAllBooks(אינדוקס הספרייה המלא) פותח ב-setBulkIndexing(enabled: true)— Tantivy מפסיק למזג סגמנטים ברקע תוך כדי הבנייה, וה-optimizeבסוף ממזג הכול ממילא. ההערה בקוד מודדת את המיזוגים תוך-כדי כ-~0.2ms למסמך של האטה.indexBooks— המסלול שמאנדקס ספרים חדשים בלבד, וזה בדיוק מה שרץ גם על ספרים אישיים וגם על ספרים שהתוסף של @יאיר-דניאל מוריד — לא נוגע ב-bulk כלל. commit יחיד בסוף, בלי optimize, ועם מיזוגי רקע רצים כל הזמן ומתחרים על ה-CPU.אותו
_indexTextBook, אותו מנוע — פשוט בלי האופטימיזציה.נקודה שנייה שכדאי לשים לב אליה:
indexBooksמשלם בכל הרצה עלות פתיחה קבועה — בניית מפת סדר קטלוג על כל הספרייה (buildKeyOrderMap) ו-warmUp של שלושה מטמונים (Generation, ReferenceBooks, BookFacetMetadata). כשמוסיפים ספר טקסט אחד קטן, ייתכן שהעלות הזו גדולה מהאינדוקס עצמו.הצד החיובי: השיפור המרכזי של 996 — קריאת התוכן כבייטים גולמיים ל-
addTextBookBytesבקריאת FFI אחת — כן חל על הספרים האלה, כי הם יושבים ב-user_books.dbועוברים באותו נתיב.התיקון להצעה שלך נראה קטן: לעטוף את
indexBooksבאותוsetBulkIndexingon/off, ואולי לדלג על ה-warmUp כשאין מה לאנדקס. -
אם אלה קבצי טקסט, אז ההסבר על PDF לא רלוונטי כאן — והפער כולו הוא מצב ה-bulk. אימתתי בקוד (
lib/indexing/repository/indexing_repository.dart, ענף dev):indexAllBooks(אינדוקס הספרייה המלא) פותח ב-setBulkIndexing(enabled: true)— Tantivy מפסיק למזג סגמנטים ברקע תוך כדי הבנייה, וה-optimizeבסוף ממזג הכול ממילא. ההערה בקוד מודדת את המיזוגים תוך-כדי כ-~0.2ms למסמך של האטה.indexBooks— המסלול שמאנדקס ספרים חדשים בלבד, וזה בדיוק מה שרץ גם על ספרים אישיים וגם על ספרים שהתוסף של @יאיר-דניאל מוריד — לא נוגע ב-bulk כלל. commit יחיד בסוף, בלי optimize, ועם מיזוגי רקע רצים כל הזמן ומתחרים על ה-CPU.אותו
_indexTextBook, אותו מנוע — פשוט בלי האופטימיזציה.נקודה שנייה שכדאי לשים לב אליה:
indexBooksמשלם בכל הרצה עלות פתיחה קבועה — בניית מפת סדר קטלוג על כל הספרייה (buildKeyOrderMap) ו-warmUp של שלושה מטמונים (Generation, ReferenceBooks, BookFacetMetadata). כשמוסיפים ספר טקסט אחד קטן, ייתכן שהעלות הזו גדולה מהאינדוקס עצמו.הצד החיובי: השיפור המרכזי של 996 — קריאת התוכן כבייטים גולמיים ל-
addTextBookBytesבקריאת FFI אחת — כן חל על הספרים האלה, כי הם יושבים ב-user_books.dbועוברים באותו נתיב.התיקון להצעה שלך נראה קטן: לעטוף את
indexBooksבאותוsetBulkIndexingon/off, ואולי לדלג על ה-warmUp כשאין מה לאנדקס.@Otzaria-Bot @י.-פל. שים לב להודעת הבוט, יש כאן כמה שדרוגים חשובים ונחוצים.
שלום! נראה שהשיחה הזו מעניינת אותך, אבל עדיין אין לך חשבון.
נמאס לכם לגלול בין אותם הפוסטים בכל ביקור? כשנרשמים לחשבון, תמיד תחזרו בדיוק למקום שבו הייתם קודם, ותוכלו לבחור לקבל התראות על תגובות חדשות (בין אם במייל, ובין אם בהתראת פוש). תוכלו גם לשמור סימניות ולפרגן ב-upvote לפוסטים כדי להביע הערכה לחברי קהילה אחרים.
בעזרת התרומה שלך, הפוסט הזה יכול להיות אפילו טוב יותר 💗
הרשמה התחברות