ਤਸਵੀਰਾਂ ਨਾਲ ਭਰੇ ਏਜੰਟ ਟਰਨਾਂ ਨੂੰ ਮੈਮਰੀ ਵਿੱਚ ਰੱਖਣਾ

ਉਤਪਾਦਨ ਵਿੱਚ ਇੱਕ ਏਜੰਟ ਟਰਨ 952 MB 'ਤੇ ਮੈਮਰੀ ਤੋਂ ਬਾਹਰ ਹੋ ਗਿਆ, ਜਦੋਂ ਉਹ ਛੇ ਕੈਟਾਲਾਗ ਸਕੈਨਾਂ ਵਿੱਚੋਂ ਉਤਪਾਦ ਕੱਟ ਰਿਹਾ ਸੀ ਅਤੇ ਆਪਣੇ ਕੱਟਾਂ ਨੂੰ ਦੇਖ ਰਿਹਾ ਸੀ। ਇੱਕ ਹੀ ਲੀਕ ਨਹੀਂ ਸੀ, ਤਿੰਨ ਸਨ। ਮਾਡਲ ਨੂੰ ਹਰ ਕਾਲ ਵਿੱਚ ਟਰਨ ਦੀਆਂ ਤਸਵੀਰਾਂ ਪੂਰੇ ਆਕਾਰ ਵਿੱਚ ਦੁਬਾਰਾ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਸਨ; ਮਾਡਲ ਨੂੰ ਕਾਲ ਕਰਨ ਵਾਲੀ ਲਾਇਬ੍ਰੇਰੀ ਟਰਨ ਖਤਮ ਹੋਣ ਤੱਕ ਹਰ ਬੇਨਤੀ ਨੂੰ ਜਿਉਂਦਾ ਰੱਖਦੀ ਸੀ; ਅਤੇ ਏਜੰਟ ਫਰੇਮਵਰਕ ਦੀ ਟਰੇਸਿੰਗ ਹਰ ਕਾਲ ਦੇ ਇਨਪੁੱਟ, ਤਸਵੀਰਾਂ ਸਮੇਤ, ਪੂਰੇ ਟਰਨ ਲਈ ਰੱਖਦੀ ਸੀ। ਅਸੀਂ ਤਿੰਨੇ ਠੀਕ ਕੀਤੇ: ਤਸਵੀਰਾਂ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਛੋਟੀਆਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਹਰ ਕਾਲ ਦੀਆਂ ਤਸਵੀਰਾਂ ਕਾਲ ਖਤਮ ਹੁੰਦੇ ਹੀ ਛੱਡ ਦਿੱਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਏਜੰਟ ਤਸਵੀਰਾਂ ਕਿਵੇਂ ਵੇਖਦਾ ਹੈ

Mythex 'ਤੇ ਬਣਾਉਂਦੇ ਸਮੇਂ, ਏਜੰਟ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਦੇ ਕਲਾਉਡ ਸੈਂਡਬੌਕਸ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ। ਉਹ ਤਸਵੀਰਾਂ ਵੇਖ ਸਕਦਾ ਹੈ: ਤੁਹਾਡਾ ਅਟੈਚ ਕੀਤਾ ਸਕਰੀਨਸ਼ਾਟ, ਇੱਕ ਮੌਕਅੱਪ, ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਕੋਈ ਫਾਈਲ, ਜਾਂ ਕੋਈ ਤਸਵੀਰ ਜੋ ਉਸਨੇ ਹੁਣੇ ਆਪ ਬਣਾਈ ਹੋਵੇ। ਇਹ ਉਹਨਾਂ ਨੂੰ ਗੱਲਬਾਤ ਦੇ ਨਾਲ ਮਾਡਲ ਨੂੰ ਭੇਜ ਕੇ ਕਰਦਾ ਹੈ।

ਇੱਕ ਟਰਨ ਉਹ ਸਭ ਕੁਝ ਹੈ ਜੋ ਏਜੰਟ ਤੁਹਾਡੇ ਇੱਕ ਸੁਨੇਹੇ ਦੇ ਜਵਾਬ ਵਿੱਚ ਕਰਦਾ ਹੈ। ਇੱਕ ਟਰਨ ਦੇ ਅੰਦਰ ਏਜੰਟ ਮਾਡਲ ਨੂੰ ਕਈ ਵਾਰ ਕਾਲ ਕਰਦਾ ਹੈ: ਸੋਚਣਾ, ਇੱਕ ਟੂਲ ਚਲਾਉਣਾ, ਨਤੀਜਾ ਵੇਖਣਾ, ਫਿਰ ਮੁੜ ਸੋਚਣਾ। ਹਰ ਕਾਲ ਹੁਣ ਤੱਕ ਦੀ ਗੱਲਬਾਤ ਭੇਜਦੀ ਹੈ, ਅਤੇ ਉਸ ਵਿੱਚ ਟਰਨ ਦੀਆਂ ਤਸਵੀਰਾਂ ਵੀ ਹੁੰਦੀਆਂ ਹਨ, ਟੈਕਸਟ ਵਜੋਂ ਏਨਕੋਡ ਕੀਤੀਆਂ (base64, ਜਿਸ ਨਾਲ ਉਹ ਲਗਭਗ ਇੱਕ ਤਿਹਾਈ ਵੱਡੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ)।

ਜੋ ਟਰਨ ਕਰੈਸ਼ ਹੋਇਆ, ਉਹ ਕੁਝ ਵਾਜਬ ਕਰ ਰਿਹਾ ਸੀ। ਉਸਨੇ ਛੇ ਕੈਟਾਲਾਗ ਸਕੈਨ ਲਏ, ਹਰ ਇੱਕ ਲਗਭਗ 2.4 MB, ਉਹਨਾਂ ਵਿੱਚੋਂ ਵਿਅਕਤੀਗਤ ਉਤਪਾਦ ਕੱਟੇ, ਅਤੇ ਆਪਣੇ ਕੱਟਾਂ ਨੂੰ ਜਾਂਚਣ ਲਈ ਵਾਰ-ਵਾਰ ਪੜ੍ਹਦਾ ਰਿਹਾ। ਇਹ ਬਹੁਤ ਸਾਰੀਆਂ ਮਾਡਲ ਕਾਲਾਂ ਸਨ, ਹਰ ਇੱਕ ਵਿੱਚ ਕਈ ਵੱਡੀਆਂ ਤਸਵੀਰਾਂ।

ਕਾਰਨ 1: ਹਰ ਕਾਲ ਪੂਰੇ ਆਕਾਰ ਦੀਆਂ ਤਸਵੀਰਾਂ ਦੁਬਾਰਾ ਭੇਜਦੀ ਸੀ

ਹਰ ਮਾਡਲ ਕਾਲ ਆਪਣੀ ਬੇਨਤੀ ਦਾ ਢਾਂਚਾ ਟਰਨ ਦੀਆਂ ਤਸਵੀਰਾਂ ਪੂਰੇ ਆਕਾਰ ਵਿੱਚ ਰੱਖ ਕੇ ਮੁੜ ਬਣਾਉਂਦੀ ਸੀ, ਹਰ ਕਾਲ ਲਈ ਲਗਭਗ 20 MB base64। ਇਹ ਬੇਨਤੀ ਏਜੰਟ ਦੀ ਮੈਮਰੀ ਵਿੱਚ ਇੱਕ ਸਤਰ ਵਜੋਂ ਬਣਦੀ ਹੈ, ਇਸ ਲਈ ਹਰ ਕਾਲ ਲਗਭਗ 20 MB ਹੋਰ ਵੰਡਦੀ ਸੀ।

ਪੂਰੇ ਆਕਾਰ ਵਿੱਚ ਭੇਜਣ ਨਾਲ ਕੁਝ ਵੀ ਫਾਇਦਾ ਨਹੀਂ ਸੀ। ਮਾਡਲ ਆਪ ਤਸਵੀਰਾਂ ਨੂੰ ਲੰਬੇ ਪਾਸੇ ਲਗਭਗ 1,300 ਪਿਕਸਲ ਤੱਕ ਛੋਟਾ ਕਰ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਵਾਧੂ ਪਿਕਸਲ ਸਿਰਫ਼ ਮੈਮਰੀ ਅਤੇ ਅੱਪਲੋਡ ਦਾ ਸਮਾਂ ਖਾਂਦੇ ਸਨ।

ਹੱਲ: ਇੱਕ ਵਾਰ ਛੋਟਾ ਕਰੋ, ਛੋਟਾ ਭੇਜੋ

• 400 KB ਤੋਂ ਵੱਡੀਆਂ ਤਸਵੀਰਾਂ ਹੁਣ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ JPEG ਵਿੱਚ ਬਦਲੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਜਿਸ ਦਾ ਲੰਬਾ ਪਾਸਾ ਵੱਧ ਤੋਂ ਵੱਧ 1,568 ਪਿਕਸਲ ਹੁੰਦਾ ਹੈ। ਛੋਟੀਆਂ ਤਸਵੀਰਾਂ ਜਿਵੇਂ ਦੀਆਂ ਤਿਵੇਂ ਜਾਂਦੀਆਂ ਹਨ।
• ਬਦਲਾਅ ImageMagick ਨਾਲ ਹੁੰਦਾ ਹੈ, ਜੋ ਹਰ Mythex ਸੈਂਡਬੌਕਸ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਹਰ ਫਾਈਲ ਲਈ ਇੱਕ ਵਾਰ ਚੱਲਦਾ ਹੈ। ਜਿਸ ਟਰਨ ਵਿੱਚ ਹਰ ਕਾਲ 'ਤੇ ਉਹੀ ਸਕੈਨ ਦਿਖਦੇ ਹਨ, ਉਹ ਛੋਟੀ ਕੀਤੀ ਕਾਪੀ ਮੁੜ ਵਰਤਦਾ ਹੈ। ਇਹ ਕੈਸ਼ ਫਾਈਲ ਦੇ ਪਾਥ, ਆਕਾਰ ਅਤੇ ਸੋਧ ਦੇ ਸਮੇਂ ਨਾਲ ਚਾਬੀ ਬੱਝਦਾ ਹੈ, ਇਸ ਲਈ ਸੋਧੀ ਫਾਈਲ ਮੁੜ ਬਦਲੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਸਦੀ ਆਪਣੀ ਆਕਾਰ ਦੀ ਹੱਦ ਹੈ ਤਾਂ ਜੋ ਇਹ ਖੁਦ ਮੈਮਰੀ ਭਰਨ ਵਾਲੀ ਚੀਜ਼ ਨਾ ਬਣ ਜਾਵੇ।
• ਇੱਕ ਮਾਡਲ ਕਾਲ ਵਿੱਚ ਤਸਵੀਰਾਂ ਦਾ ਬਜਟ 16 MB ਤੋਂ 6 MB ਤੱਕ ਘਟਦਾ ਹੈ।

ਉਹੀ ਛੇ ਸਕੈਨ ਹੁਣ ਪ੍ਰਤੀ ਕਾਲ 19.7 MB ਦੀ ਥਾਂ 4.4 MB ਲੈਂਦੇ ਹਨ।

ਕਾਰਨ 2: ਮਾਡਲ ਕਲਾਇੰਟ ਕਦੇ ਬੇਨਤੀ ਛੱਡਦਾ ਹੀ ਨਹੀਂ ਸੀ

ਹਰ ਬੇਨਤੀ ਦਾ ਆਕਾਰ ਤਾਂ ਸਿਰਫ਼ ਇੱਕ ਹਿੱਸਾ ਸੀ। ਮੈਮਰੀ ਕਾਲ ਦਰ ਕਾਲ ਵਧਦੀ ਵੀ ਸੀ। ਸਾਡੇ ਸਟੇਜਿੰਗ ਵਾਤਾਵਰਣ ਵਿੱਚ, ਉਸੇ ਤਰ੍ਹਾਂ ਦਾ ਟਰਨ ਪੂਰੀ ਗਾਰਬੇਜ ਕਲੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਵੀ 369 MB ਲਾਈਵ ਮੈਮਰੀ ਰੱਖਦਾ ਸੀ, ਉਹ ਬਿੰਦੂ ਜਿੱਥੇ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹਰ ਚੀਜ਼ ਆਜ਼ਾਦ ਹੋ ਜਾਂਦੀ ਹੈ। ਹੀਪ ਸੈਂਪਲਿੰਗ ਨੇ ਸਾਰਾ ਵਾਧਾ ਮਾਡਲ ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਉਸ ਹਿੱਸੇ ਵਿੱਚ ਦਿਖਾਇਆ ਜੋ ਬੇਨਤੀ ਬਾਡੀਆਂ ਨੂੰ ਏਨਕੋਡ ਕਰਦਾ ਹੈ।

ਕਾਰਨ ਇੱਕ abort ਲਿਸਨਰ ਸੀ। ਜਦੋਂ ਤੁਸੀਂ Stop ਦਬਾਉਂਦੇ ਹੋ, ਟਰਨ ਦਾ abort signal ਚਾਲੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਸਨੂੰ ਸੁਣਨ ਵਾਲੀ ਹਰ ਬੇਨਤੀ ਰੱਦ ਹੋ ਜਾਂਦੀ ਹੈ। ਅਸੀਂ ਉਹ ਇੱਕ ਟਰਨ-ਵਿਆਪੀ ਸਿਗਨਲ ਹਰ ਬੇਨਤੀ ਨੂੰ ਦਿੰਦੇ ਸੀ। ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਜੋ ਵੀ ਸਿਗਨਲ ਮਿਲੇ ਉਸ 'ਤੇ "abort" ਲਿਸਨਰ ਜੋੜਦੀ ਹੈ, ਅਤੇ ਕਦੇ ਹਟਾਉਂਦੀ ਨਹੀਂ।

ਇਸ ਲਈ ਟਰਨ ਦੀ ਹਰ ਬੇਨਤੀ ਟਰਨ ਦੇ ਸਿਗਨਲ ਤੋਂ ਪਹੁੰਚਯੋਗ ਰਹਿੰਦੀ ਸੀ, ਜਦ ਤੱਕ ਟਰਨ ਚਲਦਾ ਰਹਿੰਦਾ: ਲਿਸਨਰ, ਜੋ ਕੰਟਰੋਲਰ ਰੱਖਦਾ ਸੀ, ਜੋ ਬੇਨਤੀ ਰੱਖਦਾ ਸੀ, ਜੋ ਪੂਰੀ ਬੇਨਤੀ ਬਾਡੀ ਅਤੇ ਉਸਦੀਆਂ ਤਸਵੀਰਾਂ ਰੱਖਦਾ ਸੀ।

ਹੱਲ: ਹਰ ਬੇਨਤੀ ਲਈ ਇੱਕ ਸਿਗਨਲ

ਹੁਣ ਹਰ ਬੇਨਤੀ ਨੂੰ ਆਪਣਾ ਸਿਗਨਲ ਮਿਲਦਾ ਹੈ। ਇਹ ਟਰਨ ਦੇ ਸਿਗਨਲ ਨਾਲ ਸਿਰਫ਼ ਉਦੋਂ ਜੁੜਦਾ ਹੈ ਜਦੋਂ ਉਹ ਬੇਨਤੀ ਚੱਲ ਰਹੀ ਹੁੰਦੀ ਹੈ, ਸਟਰੀਮ ਕੀਤੇ ਜਵਾਬ ਲਈ, ਆਖਰੀ ਚੰਕ ਪੜ੍ਹੇ ਜਾਣ ਤੱਕ, ਅਤੇ ਉਸ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਹਟ ਜਾਂਦਾ ਹੈ। Stop ਅਜੇ ਵੀ ਚੱਲ ਰਹੀ ਕਿਸੇ ਵੀ ਬੇਨਤੀ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਪਰ ਟਰਨ ਦਾ ਸਿਗਨਲ ਇੱਕ ਵੇਲੇ ਸਿਰਫ਼ ਇੱਕ ਲਿਸਨਰ ਰੱਖਦਾ ਹੈ।

ਟੈਸਟ ਇਸ ਦੇ ਤਿੰਨੇ ਹਿੱਸੇ ਕਵਰ ਕਰਦੇ ਹਨ:

• 12 ਕਾਲਾਂ ਤੋਂ ਬਾਅਦ, ਟਰਨ ਦੇ ਸਿਗਨਲ 'ਤੇ ਕੋਈ ਲਿਸਨਰ ਬਾਕੀ ਨਹੀਂ। ਠੀਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ 12 ਸਨ।
• 8 MB ਦੀਆਂ 15 ਬੇਨਤੀਆਂ ਉੱਤੇ, ਮੈਮਰੀ ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ। ਪਹਿਲਾਂ ਇਹ 128 MB ਵਧਦੀ ਸੀ।
• Stop ਦਬਾਉਣ 'ਤੇ ਅਜੇ ਵੀ ਚੱਲ ਰਹੀ ਬੇਨਤੀ ਉਸਦੀ ਸਟਰੀਮ ਦੇ ਵਿਚਕਾਰ ਰੱਦ ਹੁੰਦੀ ਹੈ।

ਕਾਰਨ 3: ਟਰੇਸਿੰਗ ਹਰ ਕਾਲ ਦੇ ਇਨਪੁੱਟ ਰੱਖਦੀ ਸੀ

ਇੱਕ ਹੀਪ ਸਨੈਪਸ਼ਾਟ ਨੇ ਤੀਜਾ ਰੱਖਣ ਵਾਲਾ ਦਿਖਾਇਆ: ਹਰ ਮਾਡਲ ਕਾਲ ਲਈ ਲਗਭਗ 6 MB। ਇਹ ਏਜੰਟ ਫਰੇਮਵਰਕ ਦੀ ਈਵੈਂਟ ਸਟਰੀਮਿੰਗ ਤੋਂ ਆਇਆ। ਇਹ ਟਰਨ ਦੀ ਹਰ ਮਾਡਲ ਕਾਲ ਨੂੰ ਟਰਨ ਦੇ ਬੱਚੇ ਵਜੋਂ ਦਰਜ ਕਰਦੀ ਹੈ, ਇਨਪੁੱਟਾਂ ਸਮੇਤ, ਟਰਨ ਖਤਮ ਹੋਣ ਤੱਕ। ਹਰ ਕਾਲ ਨਾਲ ਜੁੜੀ ਹਰ ਤਸਵੀਰ ਉਸਦੇ ਨਾਲ ਮੈਮਰੀ ਵਿੱਚ ਰਹਿੰਦੀ ਸੀ।

ਹੱਲ: ਕਾਲ ਵਾਪਸ ਆਉਣ 'ਤੇ ਤਸਵੀਰਾਂ ਖਾਲੀ ਕਰੋ

ਤਸਵੀਰਾਂ ਸਿਰਫ਼ ਉਹਨਾਂ ਸੁਨੇਹਿਆਂ ਨਾਲ ਜੁੜੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਕਿਸੇ ਖਾਸ ਮਾਡਲ ਕਾਲ ਲਈ ਬਣਦੇ ਹਨ। ਇਹ ਗੱਲਬਾਤ ਦੀ ਸੰਭਾਲੀ ਹੋਈ ਸਥਿਤੀ ਵਿੱਚ ਕਦੇ ਸੰਭਾਲੀਆਂ ਨਹੀਂ ਜਾਂਦੀਆਂ। ਇਸ ਲਈ ਕਾਲ ਵਾਪਸ ਆਉਣ ਤੋਂ ਬਾਅਦ, ਉਹਨਾਂ ਸੁਨੇਹਿਆਂ ਵਿੱਚ ਤਸਵੀਰ ਡੇਟਾ ਖਾਲੀ ਕਰਨਾ ਸੁਰੱਖਿਅਤ ਹੈ। ਟਰੇਸ ਕਾਲ ਦਾ ਟੈਕਸਟ ਰਿਕਾਰਡ ਰੱਖਦਾ ਹੈ; ਪਿਕਸਲ ਹਟ ਜਾਂਦੇ ਹਨ।

ਇੱਕ ਗੱਲ ਅਹਿਮ ਸੀ: ਤਸਵੀਰਾਂ ਨੂੰ ਥਾਂ 'ਤੇ ਹੀ ਖਾਲੀ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਟਰੇਸਰ ਇੱਕ ਸੁਨੇਹੇ ਦੇ ਕਈ ਹਵਾਲਿਆਂ ਰਾਹੀਂ ਉਸੇ ਤਸਵੀਰ ਡੇਟਾ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਨਵੀਂ ਖਾਲੀ ਸੂਚੀ ਰੱਖਣ ਨਾਲ ਅਸਲੀ, ਪਿਕਸਲ ਸਮੇਤ, ਅਜੇ ਵੀ ਪਹੁੰਚਯੋਗ ਰਹਿੰਦਾ। ਸੰਭਾਲੀ ਹੋਈ ਗੱਲਬਾਤ ਦੀ ਸਥਿਤੀ ਕਦੇ ਬਦਲੀ ਨਹੀਂ ਜਾਂਦੀ।

ਇੱਕ ਟੈਸਟ ਏਜੰਟ ਦੇ ਗ੍ਰਾਫ ਨੂੰ ਉਸੇ ਈਵੈਂਟ ਸਟਰੀਮਿੰਗ ਹੇਠ ਚਲਾਉਂਦਾ ਹੈ, ਹਰ ਕਾਲ 'ਤੇ 4 MB ਦੀ ਤਸਵੀਰ ਨਾਲ। ਠੀਕ ਕਰਨ ਤੋਂ ਬਿਨਾਂ, 16 ਕਾਲਾਂ ਵਿੱਚ ਮੈਮਰੀ 77 MB ਵਧੀ। ਠੀਕ ਕਰਨ ਨਾਲ ਮੈਮਰੀ ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ।

ਅਸੀਂ ਇਸ ਤੋਂ ਕੀ ਸਿੱਖਿਆ

• ਮੈਮਰੀ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪਰਤਾਂ ਵਿੱਚ ਆ ਸਕਦੀਆਂ ਹਨ। ਤਿੰਨ ਵੱਖਰੇ ਕਾਰਨ ਹਰ ਇੱਕ ਤਸਵੀਰਾਂ ਨੂੰ ਬਹੁਤ ਦੇਰ ਰੱਖ ਰਿਹਾ ਸੀ, ਅਤੇ ਟਰਨ ਮੈਮਰੀ ਵਿੱਚ ਰਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨੇ ਹਟਾਉਣੇ ਪਏ।
• ਜੋ ਵੀ ਤੁਸੀਂ ਕਿਸੇ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਦਿੰਦੇ ਹੋ, ਉਹ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਸਿਗਨਲ ਅਤੇ ਇੱਕ ਟਰੇਸ ਦੋਵੇਂ ਉਹਨਾਂ ਕਾਲਾਂ ਤੋਂ ਵੱਧ ਜਿਉਂਦੇ ਰਹੇ ਜਿਨ੍ਹਾਂ ਲਈ ਉਹ ਦਿੱਤੇ ਗਏ ਸਨ। ਜਦੋਂ ਮੈਮਰੀ ਹਰ ਕਾਲ ਨਾਲ ਵਧੇ, ਤਾਂ ਵੇਖੋ ਕਿ ਕਾਲ ਕਿਹੜੀਆਂ ਲੰਮੇ ਸਮੇਂ ਵਾਲੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਛੂਹਦੀ ਹੈ।
• ਜੋ ਦੂਜਾ ਧਿਰ ਸੁੱਟ ਦਿੰਦਾ ਹੈ, ਉਹ ਨਾ ਭੇਜੋ। ਪਿਕਸਲ ਜੋ ਮਾਡਲ ਵੈਸੇ ਵੀ ਛੱਡ ਦਿੰਦਾ, ਹਰ ਕਾਲ 'ਤੇ ਸਾਡੀ ਮੈਮਰੀ ਖਾਂਦੇ ਸਨ।
• ਮੈਮਰੀ ਨੂੰ ਸਿੱਧਾ ਟੈਸਟ ਕਰੋ। ਹਰ ਠੀਕ ਕਰਨ ਨਾਲ ਇੱਕ ਟੈਸਟ ਆਇਆ ਜੋ ਹੀਪ ਵਾਧਾ ਜਾਂ ਲਿਸਨਰ ਗਿਣਤੀ ਮਾਪਦਾ ਹੈ, ਤਾਂ ਜੋ ਵਾਪਸੀ ਕਰਨ ਵਾਲੀ ਗਲਤੀ ਇੱਕ ਕਰੈਸ਼ ਵਜੋਂ ਨਹੀਂ, ਇੱਕ ਨੰਬਰ ਵਜੋਂ ਦਿਖੇ।

ਇਹ ਏਜੰਟ ਤੋਂ ਥੋੜ੍ਹੇ ਸਮੇਂ ਵਿੱਚ ਮੈਮਰੀ ਦੀ ਦੂਜੀ ਕਹਾਣੀ ਹੈ; ਪਹਿਲੀ ਸੀ ਇੱਕ ਪ੍ਰੋਗਰੈਸ ਲੇਬਲ ਜੋ 41,000 ਵਾਰ ਦੁਬਾਰਾ ਭੇਜਿਆ ਗਿਆ। ਏਜੰਟ ਕੀ ਹੈ ਅਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਇਹ ਜਾਣਨ ਲਈ ਸਾਡੀ AI ਏਜੰਟ ਗਾਈਡ ਅਤੇ ਚੈਟ ਦੇ ਦਸਤਾਵੇਜ਼ ਵੇਖੋ।