ಚಿತ್ರ-ಭಾರಿ ಏಜೆಂಟ್ ಸುತ್ತುಗಳನ್ನು ಮೆಮೊರಿಯೊಳಗೆ ಇಡುವುದು

ಉತ್ಪಾದನೆಯಲ್ಲಿದ್ದ ಏಜೆಂಟ್ ಸುತ್ತು ಆರು ಕ್ಯಾಟಲಾಗ್ ಸ್ಕ್ಯಾನ್‌ಗಳಿಂದ ಉತ್ಪನ್ನಗಳನ್ನು ಕತ್ತರಿಸಿ, ಆ ಕ್ರಾಪ್‌ಗಳನ್ನು ನೋಡುವಾಗ 952 MB ನಲ್ಲಿ ಮೆಮೊರಿ ಖಾಲಿಯಾಯಿತು. ಒಂದೇ ಸೋರಿಕೆ ಇರಲಿಲ್ಲ — ಮೂರು ಇದ್ದವು. ಮಾದರಿಗೆ ಮಾಡಿದ ಪ್ರತಿ ಕರೆಯೂ ಆ ಸುತ್ತಿನ ಚಿತ್ರಗಳನ್ನು ಪೂರ್ಣ ಗಾತ್ರದಲ್ಲಿ ಮತ್ತೆ ಕಳುಹಿಸುತ್ತಿತ್ತು; ಮಾದರಿಯನ್ನು ಕರೆಯಲು ಬಳಸಿದ ಲೈಬ್ರರಿ ಸುತ್ತು ಮುಗಿಯುವವರೆಗೂ ಪ್ರತಿ ವಿನಂತಿಯನ್ನು ಜೀವಂತವಾಗಿಡುತ್ತಿತ್ತು; ಮತ್ತು ಏಜೆಂಟ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ನ ಟ್ರೇಸಿಂಗ್ ಪ್ರತಿ ಕರೆಯ ಇನ್‌ಪುಟ್‌ಗಳನ್ನು, ಚಿತ್ರಗಳೂ ಸೇರಿ, ಇಡೀ ಸುತ್ತಿಗಾಗಿ ಉಳಿಸಿಕೊಂಡಿತ್ತು. ಮೂರನ್ನೂ ನಾವು ಸರಿಪಡಿಸಿದ್ದೇವೆ: ಚಿತ್ರಗಳನ್ನು ಕಳುಹಿಸುವ ಮೊದಲೇ ಚಿಕ್ಕದಾಗಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಕರೆಯ ಚಿತ್ರಗಳನ್ನು ಕರೆ ಮುಗಿದ ತಕ್ಷಣ ಬಿಡುಗಡೆ ಮಾಡಲಾಗುತ್ತದೆ.

ಏಜೆಂಟ್ ಚಿತ್ರಗಳನ್ನು ಹೇಗೆ ನೋಡುತ್ತದೆ

ನೀವು Mythex ನಲ್ಲಿ ನಿರ್ಮಿಸುವಾಗ, ಏಜೆಂಟ್ ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನ ಕ್ಲೌಡ್ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಅದು ಚಿತ್ರಗಳನ್ನು ನೋಡಬಲ್ಲದು — ನೀವು ಲಗತ್ತಿಸಿದ ಸ್ಕ್ರೀನ್‌ಶಾಟ್, ಮಾಕಪ್, ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನಲ್ಲಿರುವ ಫೈಲ್, ಅಥವಾ ಅದು ಸ್ವತಃ ಈಗ ಉತ್ಪಾದಿಸಿದ ಚಿತ್ರ — ಅವುಗಳನ್ನು ಸಂಭಾಷಣೆಯೊಂದಿಗೆ ಮಾದರಿಗೆ ಕಳುಹಿಸುವ ಮೂಲಕ.

ಒಂದು ಸುತ್ತು ಎಂದರೆ ನಿಮ್ಮ ಒಂದು ಸಂದೇಶಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಏಜೆಂಟ್ ಮಾಡುವ ಎಲ್ಲವೂ. ಒಂದು ಸುತ್ತಿನೊಳಗೆ, ಏಜೆಂಟ್ ಮಾದರಿಯನ್ನು ಹಲವು ಸಲ ಕರೆಯುತ್ತದೆ: ಯೋಚಿಸುವುದು, ಟೂಲ್ ಚಲಾಯಿಸುವುದು, ಫಲಿತಾಂಶ ನೋಡುವುದು, ಮತ್ತೆ ಯೋಚಿಸುವುದು. ಪ್ರತಿ ಕರೆಯು ಇಲ್ಲಿಯವರೆಗಿನ ಸಂಭಾಷಣೆಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಅದರಲ್ಲಿ ಸುತ್ತಿನ ಚಿತ್ರಗಳೂ ಇರುತ್ತವೆ — ಪಠ್ಯವಾಗಿ ಎನ್‌ಕೋಡ್ ಮಾಡಲ್ಪಟ್ಟು (base64, ಇದು ಸುಮಾರು ಮೂರನೇ ಒಂದು ಭಾಗ ದೊಡ್ಡದಾಗಿಸುತ್ತದೆ).

ಕ್ರ್ಯಾಶ್ ಆದ ಸುತ್ತು ಸಮಂಜಸವಾದ ಕೆಲಸವನ್ನೇ ಮಾಡುತ್ತಿತ್ತು. ಅದು ಆರು ಕ್ಯಾಟಲಾಗ್ ಸ್ಕ್ಯಾನ್‌ಗಳನ್ನು (ಪ್ರತಿಯೊಂದೂ ಸುಮಾರು 2.4 MB) ತೆಗೆದುಕೊಂಡು, ಪ್ರತ್ಯೇಕ ಉತ್ಪನ್ನಗಳನ್ನು ಕತ್ತರಿಸಿ, ಆ ಕ್ರಾಪ್‌ಗಳನ್ನು ಪರಿಶೀಲನೆಗಾಗಿ ಮತ್ತೆ ಮತ್ತೆ ಓದುತ್ತಿತ್ತು. ಅದು ಹಲವು ಮಾದರಿ ಕರೆಗಳಾಗಿದ್ದು, ಪ್ರತಿಯೊಂದೂ ಹಲವು ದೊಡ್ಡ ಚಿತ್ರಗಳನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತಿತ್ತು.

ಕಾರಣ 1: ಪ್ರತಿ ಕರೆಯೂ ಪೂರ್ಣ ಗಾತ್ರದ ಚಿತ್ರಗಳನ್ನು ಮತ್ತೆ ಕಳುಹಿಸಿತು

ಪ್ರತಿ ಮಾದರಿ ಕರೆಯು ಸುತ್ತಿನ ಚಿತ್ರಗಳನ್ನು ಪೂರ್ಣ ಗಾತ್ರದಲ್ಲಿ ಇಟ್ಟುಕೊಂಡು ತನ್ನ ವಿನಂತಿ ದೇಹವನ್ನು ಮರುನಿರ್ಮಿಸಿತು — ಪ್ರತಿ ಕರೆಗೆ ಸುಮಾರು 20 MB base64. ದೇಹವು ಏಜೆಂಟ್‌ನ ಮೆಮೊರಿಯಲ್ಲಿ ಒಂದೇ ಸ್ಟ್ರಿಂಗ್ ಆಗಿ ನಿರ್ಮಿಸಲ್ಪಡುವುದರಿಂದ, ಪ್ರತಿ ಕರೆಯು ಮತ್ತೆ ~20 MB ಹಂಚಿತು.

ಪೂರ್ಣ ಗಾತ್ರದಲ್ಲಿ ಕಳುಹಿಸುವುದರಿಂದ ಯಾವ ಲಾಭವೂ ಇರಲಿಲ್ಲ. ಮಾದರಿಯು ಚಿತ್ರಗಳನ್ನು ತಾನೇ ಸುಮಾರು 1,300 ಪಿಕ್ಸೆಲ್‌ಗಳ ಉದ್ದ ಬದಿಗೆ ಇಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೆಚ್ಚುವರಿ ಪಿಕ್ಸೆಲ್‌ಗಳು ಮೆಮೊರಿ ಮತ್ತು ಅಪ್‌ಲೋಡ್ ಸಮಯವನ್ನಷ್ಟೇ ವೆಚ್ಚ ಮಾಡುತ್ತಿದ್ದವು.

ಪರಿಹಾರ: ಒಮ್ಮೆ ಚಿಕ್ಕದಾಗಿಸಿ, ಚಿಕ್ಕದಾಗಿ ಕಳುಹಿಸಿ

• 400 KB ಗಿಂತ ದೊಡ್ಡ ಚಿತ್ರಗಳನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು ಉದ್ದ ಬದಿಯಲ್ಲಿ ಗರಿಷ್ಠ 1,568 ಪಿಕ್ಸೆಲ್ಗಳ JPEG ಆಗಿ ಪರಿವರ್ತಿಸಲಾಗುತ್ತದೆ. ಚಿಕ್ಕವುಗಳನ್ನು ಇದ್ದಂತೆಯೇ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.
• ಪರಿವರ್ತನೆಗೆ ಪ್ರತಿ Mythex ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್‌ನಲ್ಲಿ ಇರುವ ImageMagick ಬಳಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಫೈಲ್‌ಗೆ ಒಮ್ಮೆ ಮಾತ್ರ ನಡೆಯುತ್ತದೆ. ಪ್ರತಿ ಕರೆಯಲ್ಲೂ ಒಂದೇ ಸ್ಕ್ಯಾನ್‌ಗಳನ್ನು ತೋರಿಸುವ ಸುತ್ತು ಚಿಕ್ಕದಾದ ನಕಲನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ. ಆ ಕ್ಯಾಶ್ ಫೈಲ್‌ನ ಪಥ, ಗಾತ್ರ ಮತ್ತು ಮಾರ್ಪಾಟು ಸಮಯದಿಂದ ಗುರುತಿಸಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂಪಾದಿಸಿದ ಫೈಲ್ ಮತ್ತೆ ಪರಿವರ್ತನೆಯಾಗುತ್ತದೆ. ಮತ್ತು ಅದಕ್ಕೂ ತನ್ನದೇ ಗಾತ್ರದ ಮಿತಿ ಇದೆ, ಆದ್ದರಿಂದ ಅದೇ ಮೆಮೊರಿ ತುಂಬುವ ಕಾರಣವಾಗಲಾರದು.
• ಒಂದೇ ಮಾದರಿ ಕರೆಯಲ್ಲಿ ಚಿತ್ರಗಳಿಗೆ ಇರುವ ಬಜೆಟ್ 16 MB ಯಿಂದ 6 MB ಗೆ ಇಳಿಯುತ್ತದೆ.

ಅದೇ ಆರು ಸ್ಕ್ಯಾನ್‌ಗಳು ಈಗ 19.7 MB ಬದಲು ಪ್ರತಿ ಕರೆಗೆ 4.4 MB ವೆಚ್ಚ ಮಾಡುತ್ತವೆ.

ಕಾರಣ 2: ಮಾದರಿ ಕ್ಲೈಂಟ್ ಎಂದಿಗೂ ವಿನಂತಿಯನ್ನು ಬಿಡಲಿಲ್ಲ

ಪ್ರತಿ ವಿನಂತಿಯ ಗಾತ್ರ ಇದರ ಒಂದು ಭಾಗ ಮಾತ್ರ. ಮೆಮೊರಿ ಕೂಡ ಕರೆಯಿಂದ ಕರೆಗೆ ಬೆಳೆಯುತ್ತಿತ್ತು. ನಮ್ಮ ಸ್ಟೇಜಿಂಗ್ ಪರಿಸರದಲ್ಲಿ, ಅದೇ ರೀತಿಯ ಸುತ್ತು ಸಂಪೂರ್ಣ ಗಾರ್ಬೇಜ್ ಸಂಗ್ರಹಣೆ ನಡೆದ ನಂತರವೂ 369 MB ಜೀವಂತ ಮೆಮೊರಿಯನ್ನು ಹಿಡಿದಿಟ್ಟಿತ್ತು — ಅಂದರೆ ತಲುಪಲಾಗದ ಯಾವುದೇ ವಸ್ತುವನ್ನೂ ಬಿಡುಗಡೆ ಮಾಡಬಹುದಾದ ಹಂತ. ಹೀಪ್ ಸ್ಯಾಂಪ್ಲಿಂಗ್ ಎಲ್ಲಾ ಬೆಳವಣಿಗೆಯನ್ನು ಮಾದರಿ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಯ ವಿನಂತಿ ದೇಹಗಳನ್ನು ಎನ್‌ಕೋಡ್ ಮಾಡುವ ಭಾಗದಲ್ಲಿ ತೋರಿಸಿತು.

ಕಾರಣವು ಒಂದು abort ಲಿಸನರ್ ಆಗಿತ್ತು. ನೀವು Stop ಒತ್ತಿದಾಗ, ಸುತ್ತಿನ abort ಸಿಗ್ನಲ್ ಹೊರಡುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ಕೇಳುತ್ತಿರುವ ಎಲ್ಲಾ ವಿನಂತಿಗಳು ರದ್ದಾಗುತ್ತವೆ. ನಾವು ಆ ಒಂದೇ ಸುತ್ತು-ವ್ಯಾಪಿ ಸಿಗ್ನಲ್ ಅನ್ನು ಪ್ರತಿ ವಿನಂತಿಗೆ ರವಾನಿಸುತ್ತಿದ್ದೆವು. ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿ ತಾನು ಪಡೆಯುವ ಯಾವುದೇ ಸಿಗ್ನಲ್‌ಗೆ "abort" ಲಿಸನರ್ ಸೇರಿಸುತ್ತದೆ — ಮತ್ತು ಅದನ್ನು ಎಂದಿಗೂ ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ ಸುತ್ತಿನ ಪ್ರತಿ ವಿನಂತಿಯೂ ಸುತ್ತು ಇರುವವರೆಗೆ ಸುತ್ತಿನ ಸಿಗ್ನಲ್‌ನಿಂದ ತಲುಪಬಹುದಾದಂತೆಯೇ ಉಳಿಯಿತು: ಲಿಸನರ್, ಅದು ಹಿಡಿದಿದ್ದ ಕಂಟ್ರೋಲರ್, ಅದು ಹಿಡಿದಿದ್ದ ವಿನಂತಿ, ಮತ್ತು ಚಿತ್ರಗಳೊಂದಿಗೆ ಇಡೀ ವಿನಂತಿ ದೇಹ.

ಪರಿಹಾರ: ವಿನಂತಿಗೆ ಒಂದು ಸಿಗ್ನಲ್

ಈಗ ಪ್ರತಿ ವಿನಂತಿಗೂ ತನ್ನದೇ ಸಿಗ್ನಲ್ ಸಿಗುತ್ತದೆ. ಅದು ವಿನಂತಿ ನಡೆಯುತ್ತಿರುವಾಗ ಮಾತ್ರ ಸುತ್ತಿನ ಸಿಗ್ನಲ್‌ಗೆ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ — ಸ್ಟ್ರೀಮ್ ಮಾಡಲಾದ ಉತ್ತರಕ್ಕೆ, ಕೊನೆಯ ತುಣುಕು ಓದುವವರೆಗೆ — ಮತ್ತು ತಕ್ಷಣ ಬೇರ್ಪಡುತ್ತದೆ. Stop ಇನ್ನೂ ನಡೆಯುತ್ತಿರುವ ಯಾವುದೇ ವಿನಂತಿಯನ್ನು ತಲುಪುತ್ತದೆ, ಆದರೆ ಸುತ್ತಿನ ಸಿಗ್ನಲ್ ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದೇ ಲಿಸನರ್ ಅನ್ನು ಮಾತ್ರ ಹಿಡಿದಿಡುತ್ತದೆ.

ಪರೀಕ್ಷೆಗಳು ಈ ಮೂರೂ ಭಾಗಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತವೆ:

• 12 ಕರೆಗಳ ನಂತರ ಸುತ್ತಿನ ಸಿಗ್ನಲ್‌ನಲ್ಲಿ ಯಾವ ಲಿಸನರ್ ಕೂಡ ಉಳಿಯುವುದಿಲ್ಲ. ಸರಿಪಡಿಸುವ ಮೊದಲು 12 ಇದ್ದವು.
• 8 MB ಯ 15 ವಿನಂತಿಗಳ ಮೇಲೆ, ಮೆಮೊರಿ ಸಮತಟ್ಟಾಗಿ ಉಳಿಯುತ್ತದೆ. ಮೊದಲು ಅದು 128 MB ಹೆಚ್ಚಿತ್ತು.
• ಸ್ಟ್ರೀಮ್ ನಡುವೆ ನಡೆಯುತ್ತಿರುವ ವಿನಂತಿಯನ್ನು Stop ಇನ್ನೂ ರದ್ದುಗೊಳಿಸುತ್ತದೆ.

ಕಾರಣ 3: ಟ್ರೇಸಿಂಗ್ ಪ್ರತಿ ಕರೆಯ ಇನ್‌ಪುಟ್‌ಗಳನ್ನು ಉಳಿಸಿಕೊಂಡಿತ್ತು

ಹೀಪ್ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಮೂರನೇ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವವನನ್ನು ತೋರಿಸಿತು: ಪ್ರತಿ ಮಾದರಿ ಕರೆಗೆ ಸುಮಾರು 6 MB. ಇದು ಏಜೆಂಟ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ನ ಈವೆಂಟ್ ಸ್ಟ್ರೀಮಿಂಗ್‌ನಿಂದ ಬಂದಿತ್ತು. ಅದು ಸುತ್ತಿನಲ್ಲಿ ಪ್ರತಿ ಮಾದರಿ ಕರೆಯನ್ನು ಸುತ್ತಿನ ಮಗುವಾಗಿ ದಾಖಲಿಸುತ್ತಿತ್ತು, ಇನ್‌ಪುಟ್‌ಗಳೊಂದಿಗೆ, ಸುತ್ತು ಮುಗಿಯುವವರೆಗೆ. ಪ್ರತಿ ಕರೆಗೆ ಲಗತ್ತಿಸಲಾದ ಪ್ರತಿ ಚಿತ್ರವೂ ಅದರೊಂದಿಗೆ ಮೆಮೊರಿಯಲ್ಲಿ ಉಳಿಯುತ್ತಿತ್ತು.

ಪರಿಹಾರ: ಕರೆ ಮರಳಿದ ನಂತರ ಚಿತ್ರಗಳನ್ನು ಖಾಲಿ ಮಾಡಿ

ಚಿತ್ರಗಳು ನಿರ್ದಿಷ್ಟ ಮಾದರಿ ಕರೆಗಾಗಿ ನಿರ್ಮಿಸಲಾದ ಸಂದೇಶಗಳಿಗೆ ಮಾತ್ರ ಲಗತ್ತಿಸಲ್ಪಡುತ್ತವೆ. ಅವುಗಳನ್ನು ಸಂಭಾಷಣೆಯ ಉಳಿಸಿದ ಸ್ಥಿತಿಯಲ್ಲಿ ಎಂದಿಗೂ ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಕರೆ ಮರಳಿದ ನಂತರ, ಆ ಸಂದೇಶಗಳಲ್ಲಿನ ಚಿತ್ರ ದತ್ತಾಂಶವನ್ನು ಖಾಲಿ ಮಾಡುವುದು ಸುರಕ್ಷಿತ. ಟ್ರೇಸ್ ಕರೆಯ ಪಠ್ಯ ದಾಖಲೆಯನ್ನು ಇಡುತ್ತದೆ; ಪಿಕ್ಸೆಲ್‌ಗಳು ಹೋಗುತ್ತವೆ.

ಒಂದು ವಿವರ ಮುಖ್ಯವಾಗಿತ್ತು: ಚಿತ್ರಗಳನ್ನು ಸ್ಥಳದಲ್ಲೇ ಖಾಲಿ ಮಾಡಬೇಕು. ಟ್ರೇಸರ್ ಒಂದೇ ಸಂದೇಶದ ಮೇಲೆ ಹಲವು ಉಲ್ಲೇಖಗಳ ಮೂಲಕ ಅದೇ ಚಿತ್ರ ದತ್ತಾಂಶವನ್ನು ತಲುಪಬಹುದು, ಆದ್ದರಿಂದ ಹೊಸ, ಖಾಲಿ ಪಟ್ಟಿಯನ್ನು ಬದಲಿಸಿದರೆ ಮೂಲ — ಪಿಕ್ಸೆಲ್‌ಗಳ ಸಹಿತ — ಇನ್ನೂ ತಲುಪಬಹುದಾದಂತೆಯೇ ಉಳಿಯುತ್ತಿತ್ತು. ಉಳಿಸಿದ ಸಂಭಾಷಣೆಯ ಸ್ಥಿತಿಯನ್ನು ಎಂದಿಗೂ ಮಾರ್ಪಡಿಸಲಾಗುವುದಿಲ್ಲ.

ಈವೆಂಟ್ ಸ್ಟ್ರೀಮಿಂಗ್‌ನ ಅಡಿಯಲ್ಲಿ, ಪ್ರತಿ ಕರೆಯಲ್ಲಿ 4 MB ಚಿತ್ರವಿರುವ ಏಜೆಂಟ್‌ನ ಗ್ರಾಫ್ ಅನ್ನು ಓಡಿಸುವ ಪರೀಕ್ಷೆ ಇದೆ. ಸರಿಪಡಿಸದೆ, 16 ಕರೆಗಳ ಮೇಲೆ ಮೆಮೊರಿ 77 MB ಹೆಚ್ಚಿತ್ತು. ಸರಿಪಡಿಸಿದ ನಂತರ, ಮೆಮೊರಿ ಸಮತಟ್ಟಾಗಿ ಉಳಿಯುತ್ತದೆ.

ನಾವು ಇದರಿಂದ ಕಲಿತದ್ದು

• ಮೆಮೊರಿ ಸಮಸ್ಯೆಗಳು ಪದರಗಳಲ್ಲಿ ಬರಬಹುದು. ಮೂರು ಪ್ರತ್ಯೇಕ ಕಾರಣಗಳು ಚಿತ್ರಗಳನ್ನು ತುಂಬಾ ಹೊತ್ತು ಹಿಡಿದಿಟ್ಟಿದ್ದವು, ಮತ್ತು ಮೂರೂ ಹೋಗದ ಹೊರತು ಸುತ್ತು ಮೆಮೊರಿಯೊಳಗೆ ಉಳಿಯಲಿಲ್ಲ.
• ನೀವು ಲೈಬ್ರರಿಗೆ ಕೊಟ್ಟ ಯಾವುದೇ ವಸ್ತುವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬಹುದು. ಸಿಗ್ನಲ್ ಮತ್ತು ಟ್ರೇಸ್ ಎರಡೂ ತಾವು ನೀಡಿದ ಕರೆಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕಿದ್ದವು. ಮೆಮೊರಿ ಪ್ರತಿ ಕರೆಯೊಂದಿಗೆ ಬೆಳೆದರೆ, ಕರೆ ಮುಟ್ಟುವ ದೀರ್ಘಕಾಲೀನ ವಸ್ತುಗಳನ್ನು ನೋಡಿ.
• ಇನ್ನೊಂದು ಬದಿ ಎಸೆಯುವುದನ್ನು ಕಳುಹಿಸಬೇಡಿ. ಮಾದರಿ ಹೇಗಾದರೂ ತ್ಯಜಿಸುವ ಪಿಕ್ಸೆಲ್‌ಗಳು ಪ್ರತಿ ಕರೆಯಲ್ಲೂ ನಮಗೆ ಮೆಮೊರಿ ವೆಚ್ಚ ಮಾಡಿದವು.
• ಮೆಮೊರಿಯನ್ನು ನೇರವಾಗಿ ಪರೀಕ್ಷಿಸಿ. ಪ್ರತಿ ಸರಿಪಡಿಸುವಿಕೆಯೊಂದಿಗೆ ಹೀಪ್ ಬೆಳವಣಿಗೆ ಅಥವಾ ಲಿಸನರ್ ಎಣಿಕೆಗಳನ್ನು ಅಳೆಯುವ ಪರೀಕ್ಷೆ ಬಂದಿತು, ಆದ್ದರಿಂದ ಹಿಮ್ಮುಖ ಬದಲಾವಣೆ ಕ್ರ್ಯಾಶ್ ಆಗಿ ಅಲ್ಲ, ಸಂಖ್ಯೆಯಾಗಿ ಕಾಣಿಸುತ್ತದೆ.

ಇದು ಏಜೆಂಟ್‌ನಿಂದ ಬಂದ ಎರಡನೇ ಮೆಮೊರಿ ಕಥೆ, ಕಡಿಮೆ ಅವಧಿಯಲ್ಲಿ; ಮೊದಲನೆಯದು ಪ್ರೋಗ್ರೆಸ್ ಲೇಬಲ್ 41,000 ಬಾರಿ ಮರುಕಳಿಸಿದ ಕಥೆ. ಏಜೆಂಟ್ ಎಂದರೇನು ಮತ್ತು ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ತಿಳಿಯಲು, AI ಏಜೆಂಟ್‌ಗಳು ಕುರಿತ ನಮ್ಮ ಮಾರ್ಗದರ್ಶಿ ಮತ್ತು ಚಾಟ್ ದಸ್ತಾವೇಜು ನೋಡಿ.