מיטוב השימוש בזיכרון של תוכנית דלפי שלך

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

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

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

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

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

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

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

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

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

שניהם, "DialogForm" ו- "OccasionalForm" צריכים להסיר מרשימת "צור טפסים אוטומטיים" ולהעביר לרשימה "טפסים זמינים".

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

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

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

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

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

אם הערכים המינימליים והערכים המקסימליים מוגדרים ל- $ FFFFFFFF, ה- API יקצץ באופן זמני את הגודל שנקבע ל -0, יחליף אותו מהזיכרון ומיד כשהוא מקפץ חזרה ל- RAM, ייקבע לו הכמות המינימלית החשובה ביותר של זיכרון (כל זה קורה תוך מספר ננו-שניות, לכן למשתמש זה צריך להיות לא מורגש).

קריאה לממשק API זה תתבצע רק בפרקי זמן נתונים - לא ברציפות, ולכן לא אמורה להיות השפעה כלל על הביצועים.

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

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

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

פשוט השבת את הטיימר שלך בתחילת התהליך, והפעל אותו שוב בסוף התהליך.