Mediastreamer2 VoIP ਇੰਜਣ ਦੀ ਪੜਚੋਲ ਕਰ ਰਿਹਾ ਹੈ। ਭਾਗ 12

ਲੇਖ ਸਮੱਗਰੀ ਮੇਰੇ ਤੋਂ ਲਈ ਗਈ ਹੈ ਜ਼ੈਨ ਚੈਨਲ.

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

ਕਰਾਫਟ ਫਿਲਟਰਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ

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

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

ਇਸ ਕਾਰਨ ਕਰਕੇ, ਮੀਡੀਆ ਸਟ੍ਰੀਮਰ ਫਿਲਟਰ, ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਹੌਲੀ ਨਾ ਕਰਨ ਲਈ, ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਜੋ ਸੰਦੇਸ਼ਾਂ ਦੀ ਨਕਲ ਕਰਦੇ ਸਮੇਂ ਆਸਾਨ ਕਾਪੀਆਂ ਬਣਾਉਂਦੇ ਹਨ (ਅਸੀਂ ਪਿਛਲੇ ਲੇਖ ਵਿੱਚ ਉਹਨਾਂ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਸੀ)। ਇਹ ਫੰਕਸ਼ਨ ਕਾਪੀ ਕੀਤੇ ਜਾ ਰਹੇ "ਪੁਰਾਣੇ" ਸੰਦੇਸ਼ ਤੋਂ ਡੇਟਾ ਦੇ ਇੱਕ ਬਲਾਕ ਨੂੰ "ਅਟੈਚ" ਕਰਕੇ ਸੰਦੇਸ਼ ਸਿਰਲੇਖ ਦੀ ਇੱਕ ਨਵੀਂ ਉਦਾਹਰਣ ਬਣਾਉਂਦੇ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਦੋ ਸਿਰਲੇਖ ਇੱਕ ਡੇਟਾ ਬਲਾਕ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ ਅਤੇ ਡੇਟਾ ਬਲਾਕ ਵਿੱਚ ਸੰਦਰਭ ਕਾਊਂਟਰ ਨੂੰ ਵਧਾਇਆ ਗਿਆ ਹੈ। ਪਰ ਇਹ ਦੋ ਸੰਦੇਸ਼ਾਂ ਦੀ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ। ਅਜਿਹੇ "ਸਮਾਜਿਕ" ਡੇਟਾ ਬਲਾਕ ਦੇ ਨਾਲ ਹੋਰ ਸੁਨੇਹੇ ਹੋ ਸਕਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, MS_TEE ਫਿਲਟਰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਦਰਜਨ ਅਜਿਹੀਆਂ ਲਾਈਟ ਕਾਪੀਆਂ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਇਸਦੇ ਆਉਟਪੁੱਟਾਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ। ਜੇਕਰ ਚੇਨ ਦੇ ਸਾਰੇ ਫਿਲਟਰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਤਾਂ ਪਾਈਪਲਾਈਨ ਦੇ ਅੰਤ ਤੱਕ ਇਹ ਹਵਾਲਾ ਕਾਊਂਟਰ ਜ਼ੀਰੋ ਤੱਕ ਪਹੁੰਚ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਮੈਮੋਰੀ ਰੀਲੀਜ਼ ਫੰਕਸ਼ਨ ਨੂੰ ਕਿਹਾ ਜਾਵੇਗਾ: ms_free(). ਜੇਕਰ ਕਾਲ ਨਹੀਂ ਆਉਂਦੀ, ਤਾਂ ਮੈਮੋਰੀ ਦਾ ਇਹ ਟੁਕੜਾ ਹੁਣ ਢੇਰ 'ਤੇ ਵਾਪਸ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ, ਯਾਨੀ. ਇਹ "ਲੀਕ" ਹੋ ਜਾਵੇਗਾ. ਲਾਈਟ ਕਾਪੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੀਮਤ ਆਸਾਨੀ ਨਾਲ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦਾ ਨੁਕਸਾਨ ਹੈ (ਜਿਵੇਂ ਕਿ ਨਿਯਮਤ ਕਾਪੀਆਂ ਦੇ ਨਾਲ ਹੁੰਦਾ ਹੈ) ਕਿਹੜਾ ਗ੍ਰਾਫ ਫਿਲਟਰ ਮੈਮੋਰੀ ਲੀਕ ਕਰ ਰਿਹਾ ਹੈ।

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

ਮੈਮੋਰੀ ਲੀਕ ਕਿਵੇਂ ਪ੍ਰਗਟ ਹੁੰਦੀ ਹੈ?

ਇਹ ਮੰਨਣਾ ਲਾਜ਼ੀਕਲ ਹੈ ਕਿ ਪ੍ਰੋਗਰਾਮ ਆਉਟਪੁੱਟ ਵਿੱਚ ਚੋਟੀ ਦੇ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਹਾਸਲ ਕੀਤੀ ਮੈਮੋਰੀ ਦੀ ਵੱਧ ਰਹੀ ਪ੍ਰਤੀਸ਼ਤਤਾ ਨੂੰ ਦਿਖਾਏਗਾ।

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

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

ਤਿੰਨ ਪਾਈਨ ਵਿਧੀ

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

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

ਪਰ ਇਹ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਗ੍ਰਾਫ ਵਿੱਚ ਫਿਲਟਰਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਘਟਾ ਕੇ, ਤੁਸੀਂ ਫਿਲਟਰਾਂ ਅਤੇ ਤੁਹਾਡੇ ਸਿਸਟਮ ਦੇ ਹੋਰ ਤੱਤਾਂ ਵਿਚਕਾਰ ਆਪਸੀ ਤਾਲਮੇਲ ਦੇ ਆਮ ਕੋਰਸ ਵਿੱਚ ਵਿਘਨ ਪਾਓਗੇ ਅਤੇ ਲੀਕ ਹੁਣ ਦਿਖਾਈ ਨਹੀਂ ਦੇਵੇਗੀ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਇੱਕ ਪੂਰੇ-ਆਕਾਰ ਦੇ ਗ੍ਰਾਫ ਨਾਲ ਕੰਮ ਕਰਨਾ ਪਏਗਾ ਅਤੇ ਹੇਠਾਂ ਦਿੱਤੀ ਗਈ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਵੇਗੀ।

ਸਲਾਈਡਿੰਗ ਇੰਸੂਲੇਟਰ ਵਿਧੀ

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

ਇੱਕ ਨਿਯਮਤ ਗ੍ਰਾਫ ਜਿਸ ਵਿੱਚ, ਤਿਆਰ ਮੀਡੀਆ ਸਟ੍ਰੀਮਰ ਫਿਲਟਰਾਂ ਦੇ ਨਾਲ, ਚਾਰ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਚਾਰ ਕਰਾਫਟ ਫਿਲਟਰ F1...F4 ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਜੋ ਤੁਸੀਂ ਬਹੁਤ ਸਮਾਂ ਪਹਿਲਾਂ ਬਣਾਏ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੀ ਸਹੀਤਾ ਬਾਰੇ ਕੋਈ ਸ਼ੱਕ ਨਹੀਂ ਹੈ। ਹਾਲਾਂਕਿ, ਮੰਨ ਲਓ ਕਿ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਈਆਂ ਕੋਲ ਮੈਮੋਰੀ ਲੀਕ ਹੈ। ਵਿਸ਼ਲੇਸ਼ਕ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਸਾਡੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਚਲਾਉਂਦੇ ਹੋਏ, ਅਸੀਂ ਇਸਦੀ ਰਿਪੋਰਟ ਤੋਂ ਸਿੱਖਦੇ ਹਾਂ ਕਿ ਇੱਕ ਨਿਸ਼ਚਿਤ ਫਿਲਟਰ ਨੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਮਾਤਰਾ ਵਿੱਚ ਮੈਮੋਰੀ ਲਈ ਬੇਨਤੀ ਕੀਤੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਈ ਵਾਰ ਹੀਪ N ਵਿੱਚ ਵਾਪਸ ਨਹੀਂ ਕੀਤਾ ਹੈ। ਤੁਸੀਂ ਆਸਾਨੀ ਨਾਲ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ MS_VOID_SOURCE ਕਿਸਮ ਦੇ ਅੰਦਰੂਨੀ ਫਿਲਟਰ ਫੰਕਸ਼ਨਾਂ ਦਾ ਲਿੰਕ ਹੋਵੇਗਾ। ਉਸਦਾ ਕੰਮ ਢੇਰ ਤੋਂ ਯਾਦਦਾਸ਼ਤ ਲੈਣਾ ਹੈ। ਹੋਰ ਫਿਲਟਰਾਂ ਨੂੰ ਇਸ ਨੂੰ ਉੱਥੇ ਵਾਪਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਉਹ. ਅਸੀਂ ਲੀਕ ਦੇ ਤੱਥ ਦਾ ਪਤਾ ਲਗਾਵਾਂਗੇ।

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

ਅਸੀਂ ਵੋਇਡਸੋਰਸ ਫਿਲਟਰ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਆਈਸੋਲਟਰ ਨੂੰ ਚਾਲੂ ਕਰਦੇ ਹਾਂ:

ਅਸੀਂ ਵਿਸ਼ਲੇਸ਼ਕ ਨਾਲ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਂਦੇ ਹਾਂ, ਅਤੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਇਸ ਵਾਰ ਵਿਸ਼ਲੇਸ਼ਕ ਇੰਸੂਲੇਟਰ ਨੂੰ ਦੋਸ਼ੀ ਠਹਿਰਾਏਗਾ। ਆਖ਼ਰਕਾਰ, ਇਹ ਉਹ ਹੈ ਜੋ ਹੁਣ ਡੇਟਾ ਦੇ ਬਲਾਕ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਫਿਰ ਅਣਜਾਣ ਲਾਪਰਵਾਹੀ ਫਿਲਟਰ (ਜਾਂ ਫਿਲਟਰ) ਦੁਆਰਾ ਗੁਆਚ ਜਾਂਦੇ ਹਨ. ਅਗਲਾ ਕਦਮ ਹੈ ਇੰਸੂਲੇਟਰ ਨੂੰ ਚੇਨ ਦੇ ਨਾਲ ਸੱਜੇ ਪਾਸੇ, ਇੱਕ ਫਿਲਟਰ ਦੁਆਰਾ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨਾ। ਇਸ ਲਈ, ਕਦਮ-ਦਰ-ਕਦਮ ਆਈਸੋਲਟਰ ਨੂੰ ਸੱਜੇ ਪਾਸੇ ਲਿਜਾਉਂਦੇ ਹੋਏ, ਸਾਨੂੰ ਅਜਿਹੀ ਸਥਿਤੀ ਮਿਲੇਗੀ ਜਿੱਥੇ ਅਗਲੀ ਵਿਸ਼ਲੇਸ਼ਕ ਰਿਪੋਰਟ ਵਿੱਚ "ਲੀਕ" ਮੈਮੋਰੀ ਬਲਾਕਾਂ ਦੀ ਗਿਣਤੀ ਘੱਟ ਜਾਵੇਗੀ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸ ਪੜਾਅ 'ਤੇ ਇੰਸੂਲੇਟਰ ਸਮੱਸਿਆ ਫਿਲਟਰ ਦੇ ਤੁਰੰਤ ਬਾਅਦ ਚੇਨ ਵਿੱਚ ਸੀ. ਜੇ ਸਿਰਫ ਇੱਕ "ਬੁਰਾ" ਫਿਲਟਰ ਸੀ, ਤਾਂ ਲੀਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਲੋਪ ਹੋ ਜਾਵੇਗਾ. ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਸਮੱਸਿਆ ਵਾਲੇ ਫਿਲਟਰ (ਜਾਂ ਕਈ ਵਿੱਚੋਂ ਇੱਕ) ਦਾ ਸਥਾਨੀਕਰਨ ਕੀਤਾ। ਫਿਲਟਰ ਨੂੰ "ਸਥਿਰ" ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਚੇਨ ਦੇ ਨਾਲ-ਨਾਲ ਆਈਸੋਲਟਰ ਨੂੰ ਸੱਜੇ ਪਾਸੇ ਲਿਜਾਣਾ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹਾਂ ਜਦੋਂ ਤੱਕ ਅਸੀਂ ਮੈਮੋਰੀ ਲੀਕ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਰਾ ਨਹੀਂ ਦਿੰਦੇ।

ਇੱਕ ਆਈਸੋਲਟਰ ਫਿਲਟਰ ਨੂੰ ਲਾਗੂ ਕਰਨਾ

ਆਈਸੋਲਟਰ ਲਾਗੂ ਕਰਨਾ ਇੱਕ ਨਿਯਮਤ ਫਿਲਟਰ ਵਾਂਗ ਦਿਸਦਾ ਹੈ। ਸਿਰਲੇਖ ਫਾਈਲ:

/* Файл iso_filter.h  Описание изолирующего фильтра. */

#ifndef iso_filter_h
#define iso_filter_h

/* Задаем идентификатор фильтра. */
#include <mediastreamer2/msfilter.h>

#define MY_ISO_FILTER_ID 1024

extern MSFilterDesc iso_filter_desc;

#endif

ਫਿਲਟਰ ਆਪਣੇ ਆਪ:

/* Файл iso_filter.c  Описание изолирующего фильтра. */

#include "iso_filter.h"

    static void
iso_init (MSFilter * f)
{
}
    static void
iso_uninit (MSFilter * f)
{
}

    static void
iso_process (MSFilter * f)
{
    mblk_t *im;

    while ((im = ms_queue_get (f->inputs[0])) != NULL)
    {
        ms_queue_put (f->outputs[0], copymsg (im));
        freemsg (im);
    }
}

static MSFilterMethod iso_methods[] = {
    {0, NULL}
};

MSFilterDesc iso_filter_desc = {
    MY_ISO_FILTER_ID,
    "iso_filter",
    "A filter that reads from input and copy to its output.",
    MS_FILTER_OTHER,
    NULL,
    1,
    1,
    iso_init,
    NULL,
    iso_process,
    NULL,
    iso_uninit,
    iso_methods
};

MS_FILTER_DESC_EXPORT (iso_desc)

ਮੈਮੋਰੀ ਪ੍ਰਬੰਧਨ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਬਦਲਣ ਲਈ ਢੰਗ

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

OrtpMemoryFunctions reserv;
OrtpMemoryFunctions my;

reserv.malloc_fun = ortp_malloc;
reserv.realloc_fun = ortp_realloc;
reserv.free_fun = ortp_free;

my.malloc_fun = &my_malloc;
my.realloc_fun = &my_realloc;
my.free_fun = &my_free;

ortp_set_memory_functions(&my);

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

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

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

ਸਰੋਤ: www.habr.com