שאלה | סקר: הצגת PDF באוצריא: שימוש בחבילת PDF מובנית או בweb_viewer?

@י.-פל. כתב בשאלה | סקר: הצגת PDF באוצריא: שימוש בחבילת PDF מובנית או בweb_viewer?:

הסיבה שזית מהירה כ"כ, כי היא עובדת עם קובץ DB ולא עם קבצי TXT/JSON

כאן מבואר עוד סיבה
https://mitmachim.top/post/1053278

אם הולכים לטעון את כל הספר, לדעתי זה יהיה יותר איטי דרך ה-DB ממה שיש עכשיו. יש שני יתרונות עיקריים לשימוש ב-DB:
יתרון ראשון: DB מאפשר לטעון שורות ספציפיות בלי לקרוא את כל הספר מההתחלה. אבל אם ממילא טוענים את כל הספר, אז לטעון אותו יהיה יותר מהיר ב-JSON מאשר ב-DB.
יתרון שני: ביצועים טובים יותר באוצריא בנושא הקישורים. כרגע אוצריא חייבת לקרוא את כל הספר רק כדי למצוא את השורות הרלוונטיות, ולדעתי אין שום צורך בזה. כאן אכן יהיו ביצועים הרבה יותר טובים.
אבל המהירות שיש לי בזית זה לא רק זה. אני לא יודע אם יש צורך להרחיב, אבל בקיצור נמרץ:
כשמקמפלים תוכנה, כל פונקציה שמורה בטבלה. כל פעם שקוראים לפונקציה וורטאלית, התוכנה בודקת מה הקוד בטבלה הזאת. אחד ההבדלים העיקריים בין תוכנה שפועלת ב-AOT (כמו Flutter או אפילו Native באנדרואיד) לבין JIT הוא: גם אם נקרא לפונקציה וירטואלית 1000 פעמים, תוכנת AOT תלך לבדוק בטבלה הזאת אלף פעמים. אם היא תקרא אלף פעמים לפונקציה בשורה הראשונה ובשורה ה-2000, התוכנה תעשה את זה בצורה פשוטה כל פעם מחדש. (זה לא בדיוק נכון מה שאני אומר, אז אל תקפצו עליי - זה רק כדי להמחיש את הרעיון, ויש עוד הרבה הרבה אופטימיזציות שהjvm עושה, למשל אם תנאי הוא 99% נכון, ועוד, זה נושא מאוד מעניין)
זית היא תוכנת דסקטופ שפועלת במכונה וירטואלית - ה-JVM. המכונה הזאת עושה הרבה מאוד דברים כדי שהתוכנה תהיה יותר מהירה:

קומפילציה ראשונית (C1): ה-JVM מקמפלת את ה-Bytecode לקוד תואם למעבד של המחשב. זה מה שאתם רואים כשיש את מסך ההמתנה של זית - הזמן הזה הוא קומפילציה ראשונית של ה-Bytecode. זו לא קומפילציה שלמה כמו ב-JS, כי אני כבר מקמפל את קוד Kotlin ל-Bytecode. זו קומפילציה סופית: כבר קימפלתי את קוד Kotlin ו-Java ל-Bytecode שהוא דומה ל-ASM, רק בלי תאימות ייעודית למעבד מסוים. ה-JVM תקמפל את כל הקוד למשהו תואם למעבד הספציפי.
שימוש בהוראות מודרניות: רק כאן מתחיל להיות הבדל בין AOT (כמו Flutter) לבין JIT של Java. למשל, המעבדים המודרניים תומכים ב-AVX2 (הוראות מיוחדות מודרניות), אבל רוב התוכנות לא משתמשות בהן לשם תאימות. ה-JVM כן משתמשת.
מה שאני אומר אולי נשמע כמו שטויות או הגזמה, אבל Chrome לא משתמש ב-AVX2. למשל, אם תסתכלו בפורק הזה של Chrome שהוא יותר מהיר - זה גם בגלל שהוא מקמפל עם AVX2. אבל זה יוצר שני בינארים בשביל תאימות (אחד עם ואחד בלי), מה שמאוד מבלבל למשתמשים.
פרופיילינג וקומפילציה משופרת (C2): אחרי שהתוכנה רצה, ה-JVM מתחילה לעשות Profiling - כלומר מזהה אילו חלקים של הקוד הולכים ביחד, אילו חלקים רצים הרבה פעמים, ומתחילה לעשות קומפילציה שנייה שנקראת C2. לכן היא תקשר אוטומטית בין החלק שמציג את תוכן הספר לבין הרכיב שמציג את המפרשים (אם אכן מציגים את המפרשים). אחרי התהליך הזה, אומרים שהjvm התחממה.

ולפי איך שתמתמשו בתוכנה, הjim תמשיך לשפך את הc2 לפי השימוש הראילי שלכם, דבר שלעולם לא נוכל לעשות עם aot.

ולכן אם נסכם, החסרונות שזה לוקח יותר זמן להפעלה הראשונה (בערך 0.5 שנייה על מחשב מודרני אבל יכול להיות 3-4 שנייות על מחשבים קצת ישנים), שימוש יותר גבוהה בראם בלי לעשות כלום (המכונה ווירטואלית לוקחת בערך 150 מ״ב בראם) אבל מצד שני מקבלים אחרי c2 תוכנה שהיא מהירה כמעט או לפעמים אפילו יותר מאשר אם היינו כותבים אותה בcpp
[כל זה לומר, שיהיה קשה מאוד מאוד עם aot להגיע לזה.

הבל הבלים

@לא-מתייאש כתב בשאלה | סקר: הצגת PDF באוצריא: שימוש בחבילת PDF מובנית או בweb_viewer?:

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

אתה בעצם טוען שלאוצריא עדיף להישאר בצורה הנוכחית מאשר לעבור ל DB?

לא-מתייאש

@הבל-הבלים כתב בשאלה | סקר: הצגת PDF באוצריא: שימוש בחבילת PDF מובנית או בweb_viewer?:

@לא-מתייאש כתב בשאלה | סקר: הצגת PDF באוצריא: שימוש בחבילת PDF מובנית או בweb_viewer?:

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

אתה בעצם טוען שלאוצריא עדיף להישאר בצורה הנוכחית מאשר לעבור ל DB?

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

pcinfogmach

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

לא-מתייאש

@pcinfogmach כתב בשאלה | סקר: הצגת PDF באוצריא: שימוש בחבילת PDF מובנית או בweb_viewer?:

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

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

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

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

הם מתקשים כי יש binding בין דארט לrust, וdart לא נועד לדברים הללו, dart נועד בשביל להיות חילוף של js (ולא הצליח), ופלאטר נועד לשימושים פשוטים כי זה היה רק למובייל בהתחלה, זה פרוומוורק מובייל שהתאימו לדסקטופ (ועד שמה שאני יודע, אף אחד לא משתמש בו לדסקטופ חוץ מlocal send שזה עדיין נקרא אפליקצייה מאוד פשוטה), ולכן כשזה מתחיל להיות מסובך אז זה מתחיל להיות קשה, צריך לעשות הרבה עבודה ידנית והרבה באגים. זה כבר לא עניין של ביצועים. זה גם קורא הרבה באפליקציות מובייל שהופכות להיות מסובכות שזה מתחיל להיות גהינם לתחזוקה ואז חוזרים לנטיבי כי זה יותר קל יחסית אפילו שצריך לכתוב את הקוד פעמים בשפות שונות.

בקיצור הבנתם שאני לא אוהב את פלאטר ודארט