06 ਨਵੰ 2025·8 ਮਿੰਟ
John Carmack ਦੀ ਰੀਅਲ-ਟਾਈਮ ਗ੍ਰਾਫਿਕਸ ਲਈ ਪਰਫਾਰਮੈਂਸ ਮਨੋਭਾਵ
John Carmack-ਵਾਲਾ ਪਰਫਾਰਮੈਂਸ-ਪਹਿਲਾਂ ਮਨੋਭਾਵ: ਪ੍ਰੋਫਾਈਲਿੰਗ, ਫਰੇਮ-ਟਾਈਮ ਬਜਟ, ਟਰੇਡ-ਆਫ, ਅਤੇ ਜਟਿਲ ਰੀਅਲ-ਟਾਈਮ ਸਿਸਟਮਾਂ ਨੂੰ ਸ਼ਿਪ ਕਰਨ ਦੀ ਅਮਲੀ ਗਾਈਡ।
John Carmack-ਵਾਲਾ ਪਰਫਾਰਮੈਂਸ-ਪਹਿਲਾਂ ਮਨੋਭਾਵ: ਪ੍ਰੋਫਾਈਲਿੰਗ, ਫਰੇਮ-ਟਾਈਮ ਬਜਟ, ਟਰੇਡ-ਆਫ, ਅਤੇ ਜਟਿਲ ਰੀਅਲ-ਟਾਈਮ ਸਿਸਟਮਾਂ ਨੂੰ ਸ਼ਿਪ ਕਰਨ ਦੀ ਅਮਲੀ ਗਾਈਡ।
John Carmack ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਗੇਮ ਇੰਜਨਾਂ ਦਾ ਲੇਜੰਡ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਸਭ ਤੋਂ ਲਾਭਦਾਇਕ ਹਿੱਸਾ ਮਿਥੋਲੋਜੀ ਨਹੀਂ—ਇਹ ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਆਦਤਾਂ ਹਨ। ਇਹ ਕਿਸੇ ਇੱਕ ਵਿਅਕਤੀ ਦੇ ਅੰਦਾਜ਼ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਗੱਲ ਨਹੀਂ; ਇਹ ਅਮਲੀ ਸਿਧਾਂਤ ਹਨ ਜੋ ਡੈਡਲਾਈਨ ਅਤੇ ਜਟਿਲਤਾ ਦੇ ਸਮੇਂ ਤੇ ਤੇਜ਼, ਸਮੂਥ ਸਾਫ਼ਟਵੇਅਰ ਬਨਾਉਂਦੇ ਹਨ।
ਪਰਫਾਰਮੈਂਸ ਇੰਜੀਨਿਰੀੰਗ ਦਾ ਮਤਲਬ ਹੈ ਅਸਲ ਹਾਰਡਵੇਅਰ 'ਤੇ, ਅਸਲ ਹਾਲਾਤਾਂ ਵਿੱਚ ਸੌਫਟਵੇਅਰ ਨੂੰ ਇੱਕ ਗਤੀ ਨਿਸ਼ਾਨੇ 'ਤੇ ਚਲਾਉਣਾ—ਬਿਨਾਂ ਸਹੀਤਾ ਟੁੱਟੇ। ਇਹ "ਹਰ ਕੀਮਤ ਤੇ ਤੇਜ਼ ਬਣਾਓ" ਨਹੀਂ। ਇਹ ਇੱਕ ਨਿਯਮਤ ਲੂਪ ਹੈ:
ਇਹ ਮਨੋਭਾਵ Carmack ਦੇ ਕੰਮ ਵਿੱਚ ਵਾਰ-ਵਾਰ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ: ਡਾਟਾ ਨਾਲ ਗੱਲ-ਬਾਤ ਕਰੋ, ਬਦਲਾਅ ਸਪਸ਼ਟ ਰੱਖੋ, ਅਤੇ ਉਹਨਾਂ ਪਹੁੰਚਾਂ ਨੂੰ ਪਸੰਦ ਕਰੋ ਜੋ ਰੱਖ-ਰਖਾਅ ਯੋਗ ਹੋਣ।
ਰੀਅਲ-ਟਾਈਮ ਗ੍ਰਾਫਿਕਸ ਨਿਮਰਦਾਰ ਨਹੀਂ ਹੈ ਕਿਉਂਕਿ ਹਰ ਫਰੇਮ ਦਾ ਇੱਕ ਡੈਡਲਾਈਨ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਉਸਨੂੰ ਮਿਸ ਕਰਦੇ ਹੋ ਤਾਂ ਯੂਜ਼ਰ ਤੁਰੰਤ ਸਟਟਰ, ਇਨਪੁੱਟ ਲੇਟ, ਜਾਂ ਅਸਮਾਨ ਰੂਪ ਚਲਣ ਦੇ ਤੌਰ 'ਤੇ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ। ਹੋਰ ਸੌਫਟਵੇਅਰ ਈਫ਼ੀਸ਼ੰਸੀ ਨੂੰ ਕਿਊਜ਼, ਲੋਡਿੰਗ ਸਕ੍ਰੀਨ ਜਾਂ ਬੈਕਗ੍ਰਾਊਂਡ ਕੰਮ ਨਾਲ ਛੁپا ਸਕਦੇ ਹਨ। ਰੈਂਡਰਰ ਮੋਲ-ਬੋਲ ਨਹੀਂ ਕਰ ਸਕਦਾ: ਤੁਸੀਂ ਸਮੇਂ 'ਚ ਖਤਮ ਕਰੋ ਜਾਂ ਨਹੀਂ।
ਇਸ ਲਈ ਇਹ ਸਬਕ ਖੇਡਾਂ ਤੋਂ ਬਾਹਰ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। ਜਿਹੜੇ ਵੀ ਸਿਸਟਮਾਂ ਦੀ ਲੈਟੈਂਸੀ ਕੱਸ ਰਹੀ ਹੋਵੇ—UI, ਆਡੀਓ, AR/VR, ਟਰੇਡਿੰਗ, ਰੋਬੋਟਿਕਸ—ਉਹ ਬਜਟ ਸੋਚ, ਬੋਤਲਨੇਕ ਸਮਝਣ ਅਤੇ ਅਚਾਨਕ ਉਛਲਾਂ ਤੋਂ ਬਚਣ ਨਾਲ ਲਾਭ ਉਠਾਉਂਦੇ ਹਨ।
ਤੁਸੀਂ ਚੈਕਲਿਸਟ, ਅਨੁਭਾਵਕ ਨਿਯਮ ਅਤੇ ਫੈਸਲਿਆਂ ਦੇ ਪੈਟਰਨਾਂ ਲੈ ਕੇ ਜਾਵੋਗੇ ਜੋ ਤੁਹਾਡੇ ਕੰਮ 'ਤੇ ਲਾਗੂ ਹੋ ਸਕਦੇ ਹਨ: ਫਰੇਮ-ਟਾਈਮ ਜਾਂ ਲੈਟੈਂਸੀ ਬਜਟਾਂ ਕਿਵੇਂ ਸੈੱਟ ਕਰਨੀਆਂ ਨੇ, ਓਪਟੀਮਾਈਜ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੋਫਾਈਲਿੰਗ ਕਿਵੇਂ ਕਰਨੀ, ਕਿਸ "ਇੱਕ ਚੀਜ਼" ਨੂੰ ਚੁਣਨਾ ਹੈ, ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨਸ ਨੂੰ ਰੋਕਣਾ ਤਾਂ ਜੋ ਪਰਫਾਰਮੈਂਸ ਰੁਟੀਨ ਬਣ ਜਾਵੇ—ਨਾ ਕਿ ਅਖੀਰਲੇ ਮੋੜ ਦੀ ਪੈਨਿਕ।
Carmack-ਸਟਾਈਲ ਪਰਫਾਰਮੈਂਸ ਸੋਚ ਇੱਕ ਸਧਾਰਨ ਬਦਲਾਵ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ: "FPS" ਨੂੰ ਮੁੱਖ ਇਕਾਈ ਦੇ ਤੌਰ 'ਤੇ ਗੱਲ ਕਰਨਾ ਛੱਡੋ ਅਤੇ ਫਰੇਮ ਟਾਈਮ ਬਾਰੇ ਸੋਚੋ।
FPS ਇੱਕ ਰੀਸਿਪਰੋਕਲ ਹੈ ("60 FPS" ਚੰਗਾ ਲੱਗਦਾ ਹੈ, "55 FPS" ਨੇੜੇ-ਨੇੜੇ ਲੱਗਦਾ ਹੈ), ਪਰ ਯੂਜ਼ਰ ਅਨੁਭਵ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਹਰ ਫਰੇਮ ਲਈ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ—ਅਤੇ, ਸਮਾਂਗਤ ਦੇ ਤੌਰ 'ਤੇ, ਉਹਨਾਂ ਸਮਿਆਂ ਦੀ ਲਗਾਤਾਰਤਾ। 16.6 ms ਤੋਂ 33.3 ms ਦੀ ਛਲੈਕ ਤੁਰੰਤ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਭਾਵੇਂ ਸਰਾਸਰੀ FPS ਅਜੇ ਵੀ ਠੀਕ ਲੱਗਦਾ ਹੋਵੇ।
ਇੱਕ ਰੀਅਲ-ਟਾਈਮ ਉਤਪਾਦ ਕੋਲ ਇੱਕ ਹੀ ਬਜਟ ਨਹੀਂ ਹੁੰਦਾ:
ਇਹ ਬਜਟ ਇਕ-ਦੂਜੇ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹਨ। GPU ਘਟਾਉਣ ਲਈ CPU-ਭਾਰਕ ਬੈਚਿੰਗ ਜੋੜਨਾ ਪਿੱਛੇ ਲਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਮੈਮੋਰੀ ਘਟਾਉਣ ਨਾਲ ਸਟ੍ਰੀਮਿੰਗ ਜਾਂ ਡਿਕੰਪ੍ਰੈਸ਼ਨ ਦੀ ਲਾਗਤ ਵਧ ਸਕਦੀ ਹੈ।
ਜੇ ਤੁਹਾਡਾ ਟਾਰਗਟ 60 FPS ਹੈ, ਤਾਂ ਕੁੱਲ ਬਜਟ 16.6 ms ਪਰ ਫਰੇਮ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਵੰਡ ਇਸ ਤਰ੍ਹਾਂ ਹੋ ਸਕਦੀ ਹੈ:
ਜੇ CPU ਜਾਂ GPU ਬਜਟ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਤੁਸੀਂ ਫਰੇਮ ਮਿਸ ਕਰਦੇ ਹੋ। ਇਸੀ ਲਈ ਟੀਮਾਂ "CPU-bound" ਜਾਂ "GPU-bound" ਬਾਰੇ ਗੱਲ ਕਰਦੀਆਂ ਹਨ—ਇਹ ਲੇਬਲ ਨਹੀਂ, ਬਲਕਿ ਅਗਲਾ ਮਿਲੀਸੈਕਿੰਡ ਕਿੱਥੋਂ ਆ ਸਕਦਾ ਹੈ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਦਾ ਢੰਗ ਹੈ।
ਮਕਸਦ ਉੱਚ-ਪੈਦਾ ਯਾਨੀ “ਹਾਈ-ਐਂਡ PC ਤੇ ਸਭ ਤੋਂ ਵੱਧ FPS” ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਨਹੀਂ। ਮਕਸਦ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਦਰਸ਼ਕਾਂ ਲਈ ਕਾਫੀ ਤੇਜ਼ ਦਾ ਕੀ ਅਰਥ ਹੈ—ਹਾਰਡਵੇਅਰ ਟਾਰਗਟ, ਰੇਜ਼ੋਲੂਸ਼ਨ, ਬੈਟਰੀ ਸੀਮਾਵਾਂ, ਥਰਮਲ ਅਤੇ ਇਨਪੁੱਟ-ਸੰਵੇਦਨਸ਼ੀਲਤਾ—ਅਤੇ ਫਿਰ ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਖੁੱਲ੍ਹੇ ਬਜਟ ਵਜੋਂ ਸਲਾਹਮੰਦ ਰੱਖੋ।
Carmack ਦੀ ਸਧਾਰਨ ਤਰੱਕੀ "ਆਪਟੀਮਾਈਜ਼" ਨਹੀਂ ਹੁੰਦੀ—ਉਹ "ਸਰਵਿਸ ਵੀਰੀਫਾਈ" ਨਾਲ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਰੀਅਲ-ਟਾਈਮ ਪਰਫਾਰਮੈਂਸ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਸੁਰਤਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ—GC ਪੌਜ਼, "ਢੀਲੇ ਸ਼ੇਡਰ", "ਜਿਆਦਾ ਡਰਾਅ ਕਾਲ"—ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਉਹ ਤੁਹਾਡੀ ਬਿਲਡ ਤੇ ਤੁਹਾਡੇ ਹਾਰਡਵੇਅਰ 'ਤੇ ਗਲਤ ਹੁੰਦੀਆਂ ਹਨ। ਪ੍ਰੋਫਾਈਲਿੰਗ ਹੀ ਤੁਹਾਡੀ ਅਟ ਅੰਦਾਜ਼ ਨੂੰ ਸਬੂਤ ਵਿੱਚ ਬਦਲਦੀ ਹੈ।
ਪ੍ਰੋਫਾਈਲਿੰਗ ਨੂੰ ਇੱਕ ਪਹਿਲ-ਕਲਾਸ ਫੀਚਰ ਵਜੋਂ ਸੰਭਾਲੋ, ਨਾ ਕਿ ਆਖ਼ਰੀ ਮਿਅਦ ਦੀ ਬਚਾਵਾਣੀ ਵਸਤੀ। ਫਰੇਮ ਟਾਈਮ, CPU ਅਤੇ GPU ਟਾਈਮਲਾਈਨ, ਅਤੇ ਉਹ ਗਿਣਤੀਆਂ ਕੈਪਚਰ ਕਰੋ ਜੋ ਇਹ ਸਮਝਾਉਂਦੀਆਂ ਹਨ ਕਿ ਸਮਾਂ ਕਿੱਥੇ ਲੱਗ ਰਿਹਾ ਹੈ (ਤਿਕੋਣ, ਡਰਾਅ ਕਾਲ, ਸਟੇਟ ਚੇਂਜ, ਐਲੋਕੇਸ਼ਨ, ਕੈਸ਼ ਮਿਸ)। ਮਕਸਦ ਇਕ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣਾ ਹੈ: ਸਮਾਂ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਜਾ ਰਿਹਾ ਹੈ?
ਇੱਕ ਉਪਯੋਗੀ ਮਾਡਲ: ਹਰ ਸਲੇਟੀ ਫਰੇਮ ਵਿੱਚ ਇੱਕ ਚੀਜ਼ ਸੀਮਾ ਨਿਰਧਾਰਕ ਹੁੰਦੀ ਹੈ। ਸ਼ਾਇਦ GPU ਭਾਰੀ ਪਾਸ 'ਤੇ ਫਸਿਆ ਹੋਇਆ ਹੋਵੇ, CPU ਐਨੀਮੇਸ਼ਨ ਅਪਡੇਟ ਵਿੱਚ ਫਸਿਆ ਹੋਵੇ, ਜਾਂ ਮੇਨ ਥਰੇਡ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ 'ਤੇ ਰੁਕਿਆ ਹੋਵੇ। ਪਹਿਲਾਂ ਉਸ ਸੀਮਿਤ ਕਰਨ ਵਾਲੀ ਚੀਜ਼ ਨੂੰ ਲੱਭੋ; ਬਾਕੀ ਸਬ ਬਦਲੀ ਹੈ।
ਇੱਕ ਅਨੁਸ਼ਾਸਿਤ ਲੂਪ ਤੁਹਾਨੂੰ ਝਟਕਿਆਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ:
ਜੇ ਸੁਧਾਰ ਸਪਸ਼ਟ ਨਹੀਂ, ਤਾਂ ਉਸਨੂੰ ਨਾ ਮੰਨੋ—ਕਿਉਂਕਿ ਉਹ ਅਗਲੇ ਸਮੱਗਰੀ ਡ੍ਰਾਪ 'ਤੇ ਟਿਕੇਗਾ ਨਹੀਂ।
ਪਰਫਾਰਮੈਂਸ ਕੰਮ ਵਿੱਚ ਆਪਣੀ-ਆਪ ਤੇ ਮੋਹ ਹੋ ਸਕਦਾ ਹੈ:
ਪਹਿਲਾਂ ਪ੍ਰੋਫਾਈਲਿੰਗ ਤੁਹਾਡੇ ਯਤਨਾਂ ਨੂੰ ਕੇਂਦਰਿਤ ਰੱਖਦੀ ਹੈ, ਤੁਹਾਡੇ ਵਪਾਰ-ਫੈਸਲਿਆਂ ਨੂੰ ਜਾਇਜ਼ ਬਣਾਂਦੀ ਹੈ ਅਤੇ ਸਮੀਖਿਆ ਵਿੱਚ ਤੁਹਾਡੀਆਂ ਬਦਲਾਵਾਂ ਦੀ ਰੱਖਿਆ ਕਰਨੀ ਆਸਾਨ ਕਰਦੀ ਹੈ।
ਰੀਅਲ-ਟਾਈਮ ਪਰਫਾਰਮੈਂਸ ਸਮੱਸਿਆਵਾਂ ਗੰਝਲਦਾਰ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਹਰ ਚੀਜ਼ ਇੱਕਠੀ ਹੋ ਰਹੀ ਹੁੰਦੀ ਹੈ: ਗੇਮਪਲੇ, ਰੈਂਡਰਿੰਗ, ਸਟ੍ਰੀਮਿੰਗ, ਐਨੀਮੇਸ਼ਨ, UI, ਫਿਜ਼ਿਕਸ। Carmack ਦੀ ਸੁਝਵਾਂ ਇਸ ਗੁਣਜਲ ਨੂੰ ਕੱਟ ਕੇ ਡੋਮੀਨੈਂਟ ਲਿਮਿਟਰ ਲੱਭਣ ਦੀ ਹੁੰਦੀ ਹੈ—ਉਹ ਇਕ ਚੀਜ਼ ਜੋ ਮੌਜੂਦਾ ਫਰੇਮ ਟਾਈਮ ਨਿਰਧਾਰਤ ਕਰ ਰਹੀ ਹੈ।
ਜਿਆਦਾਤਰ ਮਨ੍ਹੇ ਹੇਠ ਲੱਗਦੀਆਂ ਹਨ:
ਮਕਸਦ ਇਹ ਲੇਬਲ ਲਗਾਉਣਾ ਨਹੀਂ ਕਿ ਪ_REPORT ਲਈ ਰਿਪੋਰਟ ਬਣਾਈਏ—ਮਕਸਦ ਸਹੀ ਲੀਵਰ ਚੁਣਨਾ ਹੈ।
ਕੁਝ ਤੇਜ਼ ਪ੍ਰਯੋਗ ਦੱਸ ਦੇਂਦੇ ਹਨ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਕੰਟਰੋਲ ਵਿੱਚ ਹੈ:
ਤੁਸੀਂ ਬਹੁਤ ਵਾਰੀ 10 ਸਿਸਟਮਾਂ 'ਤੇ 1% ਕਟੌਤੀ ਕਰਕੇ ਜਿੱਤਦੇ ਨਹੀਂ। ਉਸ ਵੱਡੇ ਲਾਗਤ ਜੋ ਹਰ ਫਰੇਮ ਦੁਹਰਾਈ ਜਾਂਦੀ ਹੈ, ਉਹ ਲੱਭੋ ਅਤੇ ਪਹਿਲਾਂ ਠੀਕ ਕਰੋ। ਇੱਕ ਵਾਰ ਦਾ 4 ms ਦਾ ਹਟਾਇਆ ਹੋਇਆ ਅਪਰਾਧ ਹਫ਼ਤਿਆਂ ਦੀ ਮਾਈਕ੍ਰੋ-ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਤੋਂ ਬੇਹਤਰ ਹੈ।
ਜਦ ਤੁਸੀਂ ਵੱਡਾ ਪੱਥਰ ਹਟਾ ਦਿੰਦੇ ਹੋ, ਅਗਲਾ ਵੱਡਾ ਪੱਥਰ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ। ਇਹ ਆਮ ਗੱਲ ਹੈ। ਪਰਫਾਰਮੈਂਸ ਕੰਮ ਨੂੰ ਇੱਕ ਲੂਪ ਵਜੋਂ behandelen ਕਰੋ: ਮਾਪੋ → ਬਦਲੋ → ਮੁੜ ਮਾਪੋ → ਮੁੜ ਤਰਜੀਹ ਦਿਓ। ਲਕੜੀ ਦਾ ਨਿਸ਼ਾਨ਼ ਨਹੀਂ ਪੂਰਾ ਪ੍ਰੋਫਾਈਲ ਹੈ; ਲਕੜੀ ਮਕਸਦ ਪ੍ਰਡਿਕਟੇਬਲ ਫਰੇਮ-ਟਾਈਮ ਵੱਲ ਧੀਰੇ-ਧੀਰੇ ਅੱਗੇ ਵਧਣਾ ਹੈ।
ਸਰਾਸਰੀ ਫਰੇਮ ਟਾਈਮ ਠੀਕ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਅਨੁਭਵ ਖਰਾਬ ਹੋ ਸਕਦਾ ਹੈ। ਰੀਅਲ-ਟਾਈਮ ਗ੍ਰਾਫਿਕਸ ਉਹ ਖਰਾਬ ਪਲ ਨਾਲ ਅੰਕਿਤ ਹੁੰਦਾ ਹੈ: ਵੱਡੀ ਧਮਾਕੇ ਦੇ ਦੌਰਾਨ ਫ੍ਰੇਮ ਡੀੰਗ ਹੋਣਾ, ਨਵੇਂ ਕਮਰੇ ਵਿੱਚ ਦਾਖ਼ਲ ਹੋਣ ਤੇ ਹਿਚ, ਜਾਂ ਮੀਨੂ ਖੁਲਣ ਤੇ ਤੁਰੰਤ ਰੁਕਣਾ। ਇਹ ਹੈ ਟੇਲ ਲੈਟੈਂਸੀ—ਇੱਕ-ਦੋ ਵਾਰ ਨਹੀਂ, ਪਰ ਕਾਫੀ ਵਾਰ ਐਸਾ ਹੋਣਾ ਜੋ ਯੂਜ਼ਰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰ ਲੈਂ।
ਇੱਕ ਗੇਮ ਜ਼ਿਆਦਾਤਰ 16.6 ms 'ਤੇ ਚੱਲਦੀ ਹੋਵੇ ਪਰ ਹਰ ਕੁਝ ਸਕਿੰਡਾਂ 'ਚ 60–120 ms 'ਤੇ ਸਪਾਈਕ ਕਰਦੀ ਹੋਵੇ ਤਾੰ ਅਨੁਭਵ "ਟੁੱਟਿਆ" ਮਹਿਸੂਸ ਕਰੇਗਾ, ਭਾਵੇਂ ਸਰਾਸਰੀ ਅੰਕ ਅਜੇ ਵੀ ਠੀਕ ਲੱਗੇ। ਮਨੁੱਖ ਲਹਿਰ ਦੇ ਸੰਵੇਦਨਸ਼ੀਲ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਲੰਮਾ ਫਰੇਮ ਇਨਪੁੱਟ ਭਵਿੱਖਬਾਣੀ, ਕੈਮਰਾ ਮੋਸ਼ਨ ਅਤੇ ਆਡੀਓ/ਵਿਜ਼ੂਅਲ ਸਿੰਕ ਟੁੱਟਦਾ ਹੈ।
ਸਪਾਈਕ ਉਹ ਕੰਮ ਹੁੰਦੇ ਹਨ ਜੋ ਸਮਾਂ 'ਤੇ ਇਕਸਾਰ ਨਹੀਂ ਡਾਲਦੇ:
ਸਸਤੇ ਕੰਮ ਨੂੰ ਪੇਸ਼ਗੋਇਆ ਬਨਾਉਣ ਦਾ ਮਕਸਦ ਹੈ:
ਸਿਰਫ ਇੱਕ ਔਸਤ FPS ਲਾਈਨ ਨਾਂ ਪਲੌਟ ਕਰੋ। ਪਰ-ਫਰੇਮ ਟਾਈਮ ਰਿਕਾਰਡ ਕਰੋ ਅਤੇ ਦਰਸ਼ਾਓ:
ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਸਭ ਤੋਂ ਖਰਾਬ 1% ਫਰੇਮਾਂ ਦੀ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਸਮਝਿਆ ਨਹੀਂ।
ਪਰਫਾਰਮੈਂਸ ਕੰਮ ਸੌਖਾ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਸੋਚਣਾ ਛੱਡ ਦਿੰਦੇ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਸਭ ਕੁਝ ਹੋ ਸਕਦਾ ਹੈ। Carmack ਦੀ ਸ਼ੈਲੀ ਟੀਮਾਂ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਹੈ ਕਿ ਉਹ ਟਰੇਡ-ਾਫ ਨੂੰ ਜ਼ਾਹਿਰ ਕਰਨ: ਅਸੀਂ ਕੀ ਲੈ ਰਹੇ ਹਾਂ, ਕੀ ਭੁਗਤਾਣ ਕਰ ਰਹੇ ਹਾਂ, ਅਤੇ ਕੌਣ ਅੰਤਰ ਮਹਿਸੂਸ ਕਰੇਗਾ।
ਜਿਆਦਾਤਰ ਫੈਸਲੇ ਕੁਝ ਅਕਸੀਜ਼ 'ਤੇ ਖੜੇ ਹੁੰਦੇ ਹਨ:
ਜੇ ਇੱਕ ਬਦਲਾਅ ਇੱਕ ਅਕਸੀਜ਼ ਸੁਧਾਰੇ ਪਰ ਤਿੰਨ ਹੋਰਾਂ 'ਤੇ ਬਿਨਾਂ ਦਸੇ ਬੋਝ ਪਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਦਸਤਾਵੇਜ਼ ਕਰੋ। “ਇਸ ਨਾਲ 0.4 ms GPU ਅਤੇ 80 MB VRAM ਵੱਧ ਜਾਂਦਾ ਹੈ ਤਾਂ ਸਾਫਰ ਸ਼ੈਡੋ ਮਿਲੇਗਾ” ਇੱਕ ਵਰਤਣਯੋਗ ਘੋਸ਼ਣਾ ਹੈ।
ਰੀਅਲ-ਟਾਈਮ ਗ੍ਰਾਫਿਕਸ ਸੰਪੂਰਨਤਾ ਬਾਰੇ ਨਹੀਂ; ਇਹ ਇੱਕ ਨਿਸ਼ਾਨੇ ਨੂੰ ਲਗਾਤਾਰ ਪਹੁੰਚਣ ਬਾਰੇ ਹੈ। ਟੀਮ ਆਪਣੇ ਮਨਜ਼ਿਲਾਂ ਉੱਤੇ ਸਹਿਮਤ ਹੋਵੇ: ਉਦਾਹਰਨ ਲਈ 1080p ਤੇ ਬੇਸਲਾਈਨ GPU ਤੇ ਨਿਊਨਤਮ FPS/ਅਧਿਕਤਮ ਫਰੇਮ ਟਾਈਮ, ਮਨਜ਼ੂਰ ਯੋਗ ਬੁਰੋਡ ਸਪਾਈਕ, ਅਤੇ ਪਲੇਟਫਾਰਮ ਅਨੁਸਾਰ ਮੈਮੋਰੀ ਸੀਲਿੰਗ।
ਜਦੋਂ ਟੀਮ ਇਹ ਮੰਨ ਲੈਂਦੀ ਹੈ ਕਿ 16.6 ms ਤੇ 1080p ਬੇਸਲਾਈਨ ਹੈ, ਤਾਂ ਵਿਵਾਦ ਠੋਸ ਬਣ ਜਾਂਦੇ ਹਨ: ਕੀ ਇਹ ਫੀਚਰ ਸਾਨੂੰ ਬਜਟ ਦੇ ਅੰਦਰ ਰੱਖਦਾ ਹੈ ਜਾਂ ਕਿਸੇ ਹੋਰ ਸਥਾਨ 'ਤੇ ਡਿਗਰੇਡ ਕਰਨਾ ਪਏਗਾ?
ਜਦ ਤੁਸੀਂ ਅਣਸ਼ੁੱਧ ਹੋ, ਉਹ ਵਿਕਲਪ ਚੁਣੋ ਜੋ ਵਾਪਸ ਲਾਏ ਜਾ ਸਕਦੇ ਹਨ:
ਵਾਪਸੀਯੋਗਤਾ ਸ਼ੈਡਿਊਲ ਨੂੰ ਬਚਾਉਂਦੀ ਹੈ। ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਰਸਤਾ ਸ਼ਿੱਪ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਮਹਾਨ-ਚਾਹਿਤ ਰਸਤੇ ਨੂੰ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਰੱਖ ਸਕਦੇ ਹੋ।
ਅਦਿੱਖੇ ਜਿੱਤਾਂ ਲਈ ਜ਼ਿਆਦਾ ਜਟਿਲਤਾ ਨਾ ਕਰੋ। 1% ਔਸਤ ਸੁਧਾਰ ਅਕਸਰ ਇੱਕ ਮਹੀਨੇ ਦੀ ਜਟਿਲਤਾ ਦੇ ਯੋਗ ਨਹੀਂ—ਸਿਵਾਏ ਇਸਦੇ ਕਿ ਇਹ ਸਟਟਰ ਹਟਾ ਦੇਵੇ, ਇਨਪੁੱਟ ਲੈਟੈਂਸੀ ਠੀਕ ਕਰੇ, ਜਾਂ ਕੋਈ ਮਜਬੂਤ ਮੈਮੋਰੀ ਕ੍ਰੈਸ਼ ਰੋਕੇ। ਉਹਨਾਂ ਚੰਗੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਪਹਿਲਾਂ ਰੱਖੋ ਜੋ ਖਿਡਾਰੀ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ।
ਜਦ ਪ੍ਰੋਗਰਾਮ ਸਹੀ ਹੁੰਦਾ ਹੈ ਤਾਂ ਪਰਫਾਰਮੈਂਸ ਕੰਮ ਬਹੁਤ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਕਾਫੀ ਐਸਾ ਸਮਾਂ "ਆਪਟੀਮਾਈਜ਼" ਵਿਚ ਲੰਘ ਜਾਂਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਸਹੀਤਾ ਬੱਗਾਂ ਦਾ ਪਿੱਛਾ ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਗਲਤ O(N²) ਲੂਪ, ਇੱਕ ਰੈਂਡਰ ਪਾਸ ਦੋ ਵਾਰੀ ਚੱਲਣਾ, ਇੱਕ ਮੈਮੋਰੀ ਲੀਕ ਜੋ ਹੌਲੀ-ਹੌਲੀ ਫਰੇਮ ਟਾਈਮ ਵਧਾਉਂਦੀ ਹੈ, ਜਾਂ ਰੇਸ ਕੰਡੀਸ਼ਨ ਜੋ ਅਨਿਯਮਤ ਸਟਟਰ ਬਣਾਉਂਦਾ ਹੈ।
ਇਕ ਸਥਿਰ, ਪੇਸ਼ਗੋਈਯੋਗ ਇੰਜਨ ਤੁਹਾਨੂੰ ਸਾਫ਼ ਮਾਪ ਦਿੰਦਾ ਹੈ। ਜੇ ਵਰਤਾਰਾ ਦੌੜਾਂ ਵਿੱਚ ਬਦਲ ਰਹੀ ਹੈ ਤਾਂ ਤੁਸੀਂ ਪ੍ਰੋਫਾਈਲਾਂ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਅਤੇ ਤੁਸੀਂ ਸ਼ਾਇਦ ਸ਼ੋਰ 'ਤੇ ਓਪਟੀਮਾਈਜ਼ ਕਰਨਗੇ।
ਅਨੁਸ਼ਾਸਿਤ ਅਭਿਆਸ ਜੋ ਤੇਜ਼ੀ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ:
ਕਈ ਫਰੇਮ-ਟਾਈਮ ਸਪਾਈਕ "ਹੈਜ਼ੇਨਬੱਗ" ਹੁੰਦੇ ਹਨ: ਜਦ ਤੁਸੀਂ ਲੌਗ ਜੋੜਦੇ ਹੋ ਜਾਂ ਡੀਬੱਗਰ ਚਲਾਉਂਦੇ ਹੋ ਤਾਂ ਉਹ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਲਾਜ ਡਿਟਰਮੀਨਿਸਟਿਕ ਰੀਪ੍ਰੋ ਬਣਾਉਣਾ ਹੈ।
ਇੱਕ ਛੋਟਾ, ਨਿਯੰਤਰਿਤ ਟੈਸਟ ਹਾਰਨੈੱਸ ਬਣਾਓ:
ਜਦ ਇੱਕ ਹਿਚ ਆਏ, ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਇੱਕ ਬਟਨ ਹੋ ਜੋ ਉਸਨੂੰ 100 ਵਾਰ ਦੁਹਰਾਏ—ਨਾ ਕਿ ਇਕ ਅਸਪਸ਼ਟ ਰਿਪੋਰਟ "ਕਈ ਵਾਰ 10 ਮਿੰਟਾਂ ਬਾਅਦ ਹੁੰਦਾ ਹੈ"।
ਪਰਫਾਰਮੈਂਸ ਕੰਮ ਛੋਟੇ, ਸਮੀਖਿਆਯੋਗ ਬਦਲਾਅ ਨਾਲ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ। ਵੱਡੇ ਰਿਫੈਕਟਰਿੰਗ ਇੱਕੋ ਸਮੇਂ ਕਈ ਫੇਲਰ ਮੋਡ ਲਿਆ ਸਕਦੇ ਹਨ: ਰਿਗ੍ਰੈਸ਼ਨ, ਨਵੀਂ ਐਲੋਕੇਸ਼ਨ, ਅਤੇ ਛੁਪਿਆ ਵਧਿਆ ਹੋਇਆ ਕੰਮ। ਛੋਟੇ ਡਿਫਸ ਜਿਸਨੂੰ ਅਸਾਨੀ ਨਾਲ ਸਮਝ ਕੇ ਉਹੀ ਸਵਾਲ ਪੁੱਛ ਸਕੋ: ਫਰੇਮ-ਟਾਈਮ ਵਿੱਚ ਕੀ ਬਦਲਿਆ, ਅਤੇ ਕਿਉਂ?
ਅਨੁਸ਼ਾਸਨ ਇੱਥੇ ਬਿਊਰੋਕਰੇਸੀ ਨਹੀਂ—ਇਹ ਉਹ ਹੈ ਜੋ ਮਾਪਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਤਾਂ ਜੋ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਸਪਸ਼ਟ ਹੋ ਜਾਵੇ ਨਾ ਕਿ ਧਾਰਕਾਦੀ।
ਰੀਅਲ-ਟਾਈਮ ਪਰਫਾਰਮੈਂਸ ਸਿਰਫ਼ "ਤੇਜ਼ ਕੋਡ" ਬਾਰੇ ਨਹੀਂ। ਇਹ ਉਨ੍ਹਾਂ ਕੰਮਾਂ ਨੂੰ ਐਸਾ ਤਰੀਕੇ ਨਾਲ ਅਯੋਜਿਤ ਕਰਨ ਬਾਰੇ ਹੈ ਕਿ CPU ਅਤੇ GPU ਉਹਨਾਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਕਰ ਸਕਣ। Carmack ਨੇ ਇੱਕ ਸਧਾਰਨ ਸੱਚਾਈ ਨੂੰ ਬਾਰ-ਬਾਰ ਜ਼ੋਰ ਦਿੱਤਾ: ਮਸ਼ੀਨ ਸਾਫ਼-ਸੁਥਰੀ ਡੇਟਾ ਨੂੰ ਪਸੰਦ ਕਰਦੀ ਹੈ ਅਤੇ ਅਣਲੋੜੇ ਓਵਰਹੈੱਡ ਨੂੰ ਨਪਸੰਦ ਕਰਦੀ ਹੈ।
ਆਧੁਨਿਕ CPUs ਅਦ्भੁਤ ਤੀਬਰ ਹਨ—ਜਦ ਤੱਕ ਉਹ ਮੈਮੋਰੀ ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰ ਰਹੇ। ਜੇ ਤੁਹਾਡਾ ਡੇਟਾ ਛੋਟੇ-ਛੋਟੇ ਆਬਜੈਕਟਾਂ ਵਿੱਚ ਫੈਲਿਆ ਹੋਇਆ ਹੈ, ਤਾਂ CPU ਪੁਆਇੰਟਰ ਪਿੱਛੇ-ਪਿੱਛਾ ਕਰਦਾ ਰਹੇਗਾ।
ਇੱਕ ਉਪਯੋਗੀ ਤਸਵੀਰ: ਦਸ ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਲਈ ਦਸ ਵੱਖ-ਵੱਖ ਦੁਕਾਣਾਂ 'ਤੇ ਨਾ ਜਾਓ; ਉਨ੍ਹਾਂ ਨੂੰ ਇਕ ਕਾਰਟ ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਇਕ ਵਾਰੀ ਤੁਰੋ। ਕੋਡ ਵਿੱਚ ਇਹ ਮਤਲਬ ਹੈ ਕਿ ਬਾਰ-ਬਾਰ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਮੁੱਲ ਇੱਕ-ੱਥਾਂ ਰੱਖੋ (ਅਕਸਰ ਐਰੇ ਜਾਂ ਟਾਈਟਲੀ ਪੈਕਡ ਸਟ੍ਰਕ) ਤਾਂ ਕਿ ਹਰ ਕੈਸ਼ ਲਾਈਨ ਫੇਚ ਤੁਹਾਨੂੰ ਉਹ ਡੇਟਾ ਦੇਵੇ ਜੋ ਤੁਸੀਂ ਵਰਤੋਂਗੇ।
ਬਾਰ-ਬਾਰ ਐਲੋਕੇਸ਼ਨ ਲੁਕਿਆ ਹੋਇਆ ਖ਼ਰਚ ਬਣਾਉਂਦੇ ਹਨ: ਐਲੋਕੇਟਰ ਓਵਰਹੈੱਡ, ਮੈਮੋਰੀ ਫਰੈਗਮੈਂਟੇਸ਼ਨ, ਅਤੇ ਅਣਦੇਖੇ ਰੁਕਾਵਟਾਂ। ਹਰੇਕ ਐਲੋਕੇਸ਼ਨ ਛੋਟੀ ਹੋਵੇ, ਪਰ ਲਗਾਤਾਰ ਹੋਣ 'ਤੇ ਇਹ ਹਰ ਫਰੇਮ ਇਕ ਤਕਸ ਦੇ ਤੌਰ 'ਤੇ ਲੱਗਦੀ ਹੈ।
ਆਮ ਫਿਕਸ ਬੋਰੀਂਗ ਹੁੰਦੇ ਹਨ: ਬਫਰ ਰੀਯੂਜ਼ ਕਰੋ, ਓਬਜੈਕਟ ਪੂਲਿੰਗ ਕਰੋ, ਅਤੇ ਹੌਟ ਪਾਥ ਲਈ ਲੰਬੇ-ਟਿਕਾਊ ਐਲੋਕੇਸ਼ਨ ਪਸੰਦ ਕਰੋ। ਲਕੜੀ ਦਾ ਮਕਸਦ ਚਲਾਕੀ ਨਹੀਂ—ਇਹ ਲਗਾਤਾਰਤਾ ਹੈ।
ਕਾਫੀ ਫਰੇਮ ਟਾਈਮ ਬੁਕਕੀਪਿੰਗ ਵਿੱਚ ਗੁਆ ਜਾਂਦੀ ਹੈ: ਸਟੇਟ ਚੇਂਜ, ਡਰਾਅ ਕਾਲ, ਡਰਾਈਵਰ ਵਰਕ, ਸਿਸਕਾਲ, ਅਤੇ ਥਰੇਡ ਕੋ-ਆਰਡੀਨੇਸ਼ਨ।
ਬੈਚਿੰਗ ਰੇਂਡਰਿੰਗ ਅਤੇ ਸਿਮੂਲੇਸ਼ਨ ਦਾ "ਇੱਕ ਵੱਡਾ ਕਾਰਟ" ਵਰਜਨ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਥਾਂ ਇਕਸਾਰ ਕੰਮ ਗਰੁੱਪ ਕਰੋ ਜਿਸ ਨਾਲ ਮਹਿੰਗੀਆਂ ਸਰਹੱਦਾਂ ਨੂੰ ਘੱਟ ਵਾਰ ਪਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਅਕਸਰ, ਓਵਰਹੈੱਡ ਕਟ کے ਗਣਿਤ ਓਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਤੋਂ ਵੱਡਾ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ—ਕਿਉਂਕਿ ਮਸ਼ੀਨ ਤਿਆਰ ਹੋ ਕੇ ਕੰਮ ਕਰਨ 'ਤੇ ਜ਼ਿਆਦਾ ਸਮਾਂ ਖਰਚ ਕਰਦੀ ਹੈ।
ਪਰਫਾਰਮੈਂਸ ਕੰਮ ਸਿਰਫ ਤੇਜ਼ ਕੋਡ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਘੱਟ ਕੋਡ ਰੱਖਣ ਬਾਰੇ ਵੀ ਹੈ। ਜਟਿਲਤਾ ਦਾ ਹਰ ਰੋਜ਼ ਖ਼ਰਚ ਹੁੰਦਾ ਹੈ: ਬੱਗ ਲੱਭਣਾ ਜ਼ਿਆਦਾ ਵੇਲਾ ਲੈਂਦਾ, ਫਿਕਸ ਕਰਨ ਲਈ ਹੋਰ ਟੈਸਟ ਲੋੜਦੇ, ਇਟਰੇਸ਼ਨ ਸੁਸਤ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਰਿਗ੍ਰੈਸ਼ਨ ਦੌਰਾਂ-ਦੌਰਾਂ ਛੁਪ ਕੇ ਆ ਜਾਂਦੇ ਹਨ।
ਇੱਕ "ਚਲਾਕ" ਸਿਸਟਮ ਸੋਹਣਾ ਲੱਗ ਸਕਦਾ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਡੈਡਲਾਈਨ 'ਤੇ ਨਹੀਂ ਹੋ ਅਤੇ ਇੱਕ ਫਰੇਮ ਸਪਾਈਕ ਸਿਰਫ਼ ਇਕ ਨਕਸ਼ੇ, ਇਕ GPU, ਜਾਂ ਇੱਕ ਸੈਟਿੰਗ ਕੰਬੋ ਤੇ ਦਿਖਾਈ ਦੇਂਦਾ। ਹਰ ਐਕਸਟਰਾ ਫੀਚਰ ਫਲੈਗ, ਫਾਲਬੈਕ ਪਾਥ, ਅਤੇ ਸਪੈਸ਼ਲ ਕੇਸ ਉਹ ਵਰਤਾਰਿਆਂ ਦੀ ਗਿਣਤੀ ਵਧਾਉਂਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਸਮਝਣ ਅਤੇ ਮਾਪਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਇਹ ਜਟਿਲਤਾ ਸਿਰਫ ਡਿਵੈਲਪਰ ਸਮਾਂ ਗੁਆਉਂਦੀ ਨਹੀਂ; ਅਕਸਰ ਇਹ ਰਨਟਾਈਮ ਓਵਰਹੈੱਡ ਵੀ ਪੈਦਾ ਕਰਦੀ ਹੈ (ਅਤਿਰਿਕਤ ਬ੍ਰਾਂਚ, ਐਲੋਕੇਸ਼ਨ, ਕੈਸ਼ ਮਿਸ, ਸਿੰਕ) ਜੋ ਬਾਅਦ ਵਿੱਚ ਹੀ ਦਿੱਖਦਾ ਹੈ।
ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਜੇ ਤੁਸੀਂ performance ਮਾਡਲ ਨੂੰ ਕੁਝ ਵਾਕਾਂ ਵਿੱਚ ਟੀਮਮੇਟ ਨੂੰ ਨਹੀਂ ਸਮਝਾ ਸਕਦੇ, ਤਾਂ ਅਕਸਰ ਤੁਸੀਂ ਉਸਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਓਪਟੀਮਾਈਜ਼ ਨਹੀਂ ਕਰ ਸਕੋਗੇ।
ਸਰਲ ਹੱਲਾਂ ਦੇ ਦੋ ਫਾਇਦੇ ਹਨ:
ਕਈ ਵਾਰ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਇੱਕ ਫੀਚਰ ਨੂੰ ਹਟਾਉਣਾ, ਇਕ ਵਿਕਲਪ ਕੱਟਣਾ, ਜਾਂ ਕਈ ਵੈਰੀਅੰਟਾਂ ਨੂੰ ਇਕ ਵਿੱਚ ਇਕੱਠਾ ਕਰਨਾ ਹੈ। ਘੱਟ ਫੀਚਰਾਂ ਦਾ ਮਤਲਬ ਘੱਟ ਕੋਡ ਪਾਥ, ਘੱਟ ਸਟੇਟ ਕਾਂਬੋ, ਅਤੇ ਘੱਟ ਥਾਂ ਜਿਥੇ ਪਰਫਾਰਮੈਂਸ ਚੁਪਚਾਪ ਘਟ ਸਕਦੀ ਹੈ।
ਕੋਡ ਮਿਟਾਉਣਾ ਇਕ ਗੁਣਵੱਤਾ ਕਦਮ ਵੀ ਹੈ: ਸਭ ਤੋਂ ਚੰਗਾ ਬੱਗ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਉਸ ਮੋਡੀਊਲ ਨੂੰ ਮਿਟਾ ਕੇ ਹੀ ਦੂਰ ਕਰ ਦਿੰਦੇ ਹੋ ਜੋ ਉਸਨੂੰ ਜਨਮ ਦੇ ਸਕਦਾ ਸੀ।
ਪੈਚ (ਛੁੱਟਾ ਫਿਕਸ) ਜਦ:
ਰੀਫੈਕਟਰ (ਸੰਰਚਨਾ ਸੁਧਾਰ) ਜਦ:
ਸਰਲਤਾ ਘੱਟ ਹੋਰੋ-ਚੌਕਸ ਨਹੀਂ; ਇਹ ਉਹ ਡਿਜ਼ਾਈਨ ਚੁਣਨਾ ਹੈ ਜੋ ਦਬਾਅ 'ਤੇ ਵੀ ਸਮਝਣ ਯੋਗ ਰਹੇ—ਜਦੋਂ ਪਰਫਾਰਮੈਂਸ ਸਭ ਤੋਂ ਵੱਧ ਮੈੱਟਰ ਕਰਦੀ ਹੈ।
ਕੇਵਲ ਉਹੀ ਕੰਮ ਟਿਕਦਾ ਹੈ ਜੇ ਤੁਸੀਂ ਪਤਾ ਕਰ ਸਕੋ ਕਿ ਇਹ ਕਦੋਂ ਖਿਸਕਿਆ। ਇਹੀ ਪਰਫਾਰਮੈਂਸ ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਿੰਗ ਹੈ: ਇੱਕ ਦੁਹਰਾਏ ਯੋਗ ਤਰੀਕਾ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਕੋਈ ਨਵਾਂ ਬਦਲਾਅ ਉਤਪਾਦ ਨੂੰ ਧੀਮਾ, ਘੱਟ ਸਮੂਥ, ਜਾਂ ਜ਼ਿਆਦਾ ਭਾਰ ਨਾਲ ਬਣਾਉਂਦਾ ਹੈ।
ਫੰਕਸ਼ਨਲ ਟੈਸਟਸ ਜਿਵੇਂ "ਕੀ ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ?" ਦੇ ਉਲਟ, ਰਿਗ੍ਰੈਸ਼ਨ ਟੈਸਟਸ ਇਹ ਪੁੱਛਦੇ ਹਨ "ਕੀ ਇਹ ਅਜੇ ਵੀ ਇਕੋ ਜਿਹੀ ਰਫਤਾਰ ਵਰਗੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ?" ਕੋਈ ਬਿਲਡ 100% ਕਾਰਯਕ ਰਹਿ ਸਕਦਾ ਹੈ ਪਰ ਫਿਰ ਵੀ ਇੱਕ ਮਾੜਾ ਰਿਲੀਜ਼ ਹੋ ਸਕਦਾ ਹੈ ਜੇ ਇਹ 4 ms ਫਰੇਮ-ਟਾਈਮ ਵਧਾਉਂਦਾ ਹੈ ਜਾਂ ਲੋਡਿੰਗ ਦੋਗੁਣਾ ਕਰ ਦੇਂਦਾ ਹੈ।
ਤੁਹਾਨੂੰ ਪਰਖਣ ਲਈ ਲੈਬ ਦੀ ਲੋੜ ਨਹੀਂ—ਸਿਰਫ ਸਥਿਰਤਾ ਚਾਹੀਦੀ ਹੈ।
ਉਹ ਮੈਟ੍ਰਿਕਸ ਚੁਣੋ ਜੋ ਗੱਲਬਾਤ ਕਰਨੀ ਮੁਸ਼ਕਿਲ ਹੋਵੇ:
ਸਧਾਰਨ ਸੀਮਾਵਾਂ ਪਰਿਭਾਸ਼ਤ ਕਰੋ (ਉਦਾਹਰਨ: p95 ਫਰੇਮ ਟਾਈਮ 5% ਤੋਂ ਵੱਧ ਰਿਗ੍ਰੈਸ਼ਨ ਨਾ ਹੋਵੇ)।
ਰਿਗ੍ਰੈਸ਼ਨ ਨੂੰ ਬੱਗ ਵਾਂਗ ਦਿਹਾਣੀ ਨਾਲ ਲਵੋ ਅਤੇ ਮਾਲਿਕ ਅਤੇ ਟਾਈਮਲਾਈਨ ਤੈਅ ਕਰੋ।
ਪਹਿਲਾਂ, ਬਾਇਸੈਕਟ ਕਰਕੇ ਉਹ ਬਦਲਾਅ ਲੱਭੋ ਜਿਸ ਨੇ ਇਹ ਸ਼ੁਰੂ ਕੀਤਾ। ਜੇ ਰਿਗ੍ਰੈਸ਼ਨ ਰਿਲੀਜ਼ ਰੋਕਦਾ ਹੈ, ਤਾਂ ਫੱਟੇ-ਫੱਟ ਰਿਵਰਟ ਕਰੋ ਅਤੇ ਠੀਕ ਕਰਕੇ ਦੁਬਾਰਾ ਲੈਂਡ ਕਰੋ।
ਜਦ ਤੁਸੀਂ ਠੀਕ ਕਰ ਲੈਂਦੇ ਹੋ, ਗਾਰਡਰੇਲ ਜ਼ਰੂਰ ਜੋੜੋ: ਟੈਸਟ ਰੱਖੋ, ਕੋਡ ਵਿੱਚ ਨੋਟ ਸ਼ਾਮਿਲ ਕਰੋ, ਅਤੇ ਉਮੀਦ ਰੱਖੋ ਕਿ ਬਜਟ ਕੀ ਹਨ। ਆਦਤ ਹੀ ਜਿੱਤ ਹੈ—ਪਰਫਾਰਮੈਂਸ ਉਹ ਚੀਜ਼ ਬਣ ਜਾਵੇ ਜੋ ਤੁਸੀਂ ਰੱਖਦੇ ਹੋ, ਨਾ ਕਿ ਜੋ ਤੁਸੀਂ "ਬਾਅਦ ਵਿੱਚ ਕਰੋਗੇ"।
"ਸ਼ਿਪ" ਇੱਕ ਕੈਲੰਡਰ ਘਟਨਾ ਨਹੀਂ—ਇਹ ਇੱਕ ਇੰਜੀਨਿਰੀੰਗ ਲੋੜ ਹੈ। ਇੱਕ 시스템 ਜੋ ਸਿਰਫ ਲੈਬ ਵਿੱਚ ਚੰਗਾ ਦਿਖਦਾ ਹੈ, ਜਾਂ ਜੋ ਇੱਕ ਹਫ਼ਤੇ ਦੀ ਮਨੂਅਲ ਟਿਊਨਿੰਗ ਤੋਂ ਬਾਅਦ ਹੀ ਟਾਈਮ ਹਿਟ ਕਰਦਾ ਹੈ, ਉਹ ਤਿਆਰ ਨਹੀਂ। Carmack ਦਾ ਮਨੋਭਾਵ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਹਕੀਕਤੀ ਪਾਬੰਦੀਆਂ (ਹਾਰਡਵੇਅਰ 다양ਤਾ, ਗੰਝਲਦਾਰ ਸਮੱਗਰੀ, ਅਣਅਨੁਮਾਨਤ ਖਿਡਾਰੀ ਵਰਤੀ) ਨੂੰ ਸਪੈਸ ਦਾ ਹਿੱਸਾ ਮੰਨਦਾ ਹੈ।
ਜਦ ਤੁਸੀਂ ਰਿਲੀਜ਼ ਦੇ ਨੇੜੇ ਹੋ, ਤ完ਾ ਪਰਖ਼ ਗ਼ਲਤ ਹਾਂ—ਪੂਰਨਤਾ ਤੋਂ ਜ਼ਿਆਦਾ ਪੇਸ਼ਗੋਈਯੋਗਤਾ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨਾਨ-ਨੈਗੋਸ਼ੀਏਬਲ ਨਿਯਮ ਪਰਿਭਾਸ਼ਤ ਕਰੋ: ਟਾਰਗਟ FPS, ਸਭ ਤੋਂ ਬੁਰਾ ਫਰੇਮ-ਟਾਈਮ ਸਪਾਈਕ, ਮੈਮੋਰੀ ਹੱਦਾਂ, ਅਤੇ ਲੋਡ ਸਮਾਂ। ਫਿਰ ਜੋ ਵੀ ਉਨ੍ਹਾਂ ਨੂੰ ਉਲੰਘੇ, ਉਸਨੂੰ ਬੱਗ ਸਮਝੋ—"ਪਾਲਿਸ਼" ਨਹੀਂ। ਇਹ ਪਰਫਾਰਮੈਂਸ ਕੰਮ ਨੂੰ ਵਿਅਕਤੀਗਤ ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਤੋਂ ਭਰੋਸੇਯੋਗਤਾ ਕੰਮ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਹਰ ਸਲੋਡਾਊਨ ਇਕੋ ਜਿਹੀ ਮਹੱਤਤਾ ਨਹੀਂ ਰੱਖਦੀ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਪਭੋਗੀ-ਨਜ਼ਰਅੰਦਾਜ਼ ਸਮੱਸਿਆਵਾਂ ਠੀਕ ਕਰੋ:
ਇੱਥੇ ਪ੍ਰੋਫਾਈਲਿੰਗ ਅਨੁਸ਼ਾਸਨ ਲਾਭਦਾਇਕ ਹੁੰਦੀ ਹੈ: ਤੁਸੀਂ ਨਹੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾ ਰਹੇ ਕਿ ਕਿਹੜੀ ਸਮੱਸਿਆ "ਵੱਡੀ" ਲੱਗਦੀ ਹੈ—ਤੁਸੀਂ ਮਾਪੇ ਆਧਾਰ 'ਤੇ ਫੈਸਲਾ ਕਰ ਰਹੇ ਹੋ।
ਲੇਟ-ਸਾਈਕਲ ਪਰਫਾਰਮੈਂਸ ਕੰਮ ਖ਼ਤਰਨਾਕ ਹੈ ਕਿਉਂਕਿ "ਫਿਕਸ" ਨਵੇਂ ਖ਼ਰਚ ਲਿਆ ਸਕਦਾ ਹੈ। ਸਟੇਜਡ ਰੋਲਆਊਟ ਵਰਤੋ: ਪਹਿਲਾਂ ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ ਲੈਂਡ ਕਰੋ, ਫਿਰ ਬਦਲਾਅ ਨੂੰ ਫੀਚਰ ਫਲੈਗ ਦੇ ਪਿੱਛੇ ਰੱਖੋ, ਫਿਰ ਦਾਯਰਾ ਵਧਾਓ। ਪਰਫਾਰਮੈਂਸ-ਸੇਫ ਡਿਫਾਲਟ ਪਸੰਦ ਕਰੋ—ਸੈਟਿੰਗਾਂ ਜੋ ਫਰੇਮ-ਟਾਈਮ ਨੂੰ ਬਚਾਉਂਦੀਆਂ ਹਨ ਭਾਵੇਂ ਉਹ ਵਿਜ਼ੂਅਲ ਕੁਆਲਿਟੀ ਨੰਨ੍ਹੀ ਘਟਾ ਦੇਂ।
ਜੇ ਤੁਸੀਂ ਕਈ ਪਲੇਟਫਾਰਮਾਂ ਜਾਂ ਟੀਅਰਾਂ 'ਤੇ ਸ਼ਿਪ ਕਰ ਰਹੇ ਹੋ, ਡਿਫਾਲਟਾਂ ਨੂੰ ਉਤਪਾਦਿਕ ਫੈਸਲੇ ਵਜੋਂ ਸੰਜੋ: ਥੋੜ੍ਹਾ ਘੱਟ ਸੋਹਣਾ ਲੱਗਣਾ ਵਧੇਰਾ ਅਸਥਿਰ ਮਹਿਸੂਸ ਹੋਣ ਤੋਂ ਬਿਹਤਰ ਹੈ।
ਟਰੇਡ-ਆਫ ਨੂੰ ਨਤੀਜਿਆਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰੋ: “ਇਹ ਪ੍ਰਭਾਵ ਮਿਡ-ਟੀਅਰ GPUs ਤੇ ਹਰ ਫ੍ਰੇਮ 2 ms ਲੱਗਦਾ ਹੈ, ਜੋ ਕਿ ਲੜਾਈ ਦੌਰਾਨ 60 FPS ਤੋਂ ਥੱਲੇ ਓਰ ਜਾ ਸਕਦਾ ਹੈ।” ਵਿਕਲਪ ਦਿਓ, ਨਾ ਕਿ ਲੈਕਚਰ: ਰੇਜ਼ੋਲੂਸ਼ਨ ਘਟਾਓ, ਸ਼ੇਡਰ ਸਧਾਰੋ, ਸਪawns ਦਰ ਘਟਾਓ, ਜਾਂ ਘੱਟ ਟਾਰਗਟ ਮਨ ਲਵੋ। ਸੀਮਾਵਾਂ ਸਪੱਸਟ ਵਿਕਲਪਾਂ ਨਾਲ ਜ਼ਿਆਦਾ ਸਹਿਣਯੋਗ ਬਣਦੀਆਂ ਹਨ।
ਤੁਹਾਨੂੰ ਨਵਾਂ ਇੰਜਨ ਜਾਂ ਰੀ-ਰਾਈਟ ਦੀ ਲੋੜ ਨਹੀਂ—ਸਿਰਫ਼ ਇੱਕ ਦੁਹਰਾਏ ਯੋਗ ਲੂਪ ਜੋ ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਦਿਸ਼ਾ-ਯੋਗ, ਟੈਸਟਯੋਗ, ਅਤੇ ਗਲਤੀ ਨਾਲ ਭੁੱਲਣਾ ਮੁਸ਼ਕਿਲ ਬਣਾਵੇ।
ਮਾਪੋ: ਫਰੇਮ-ਟਾਈਮ ਅਤੇ ਮੁੱਖ ਉਪ-ਸਿਸਟਮਾਂ ਲਈ ਬੇਸਲਾਈਨ ਕੈਪਚਰ ਕਰੋ (ਔਸਤ, p95, ਸਭ ਤੋਂ ਵੱਡਾ ਸਪਾਈਕ)।
ਬਜਟ: CPU ਅਤੇ GPU (ਅਤੇ ਜੇ ਤੰਗ ਹੋ ਤਾਂ ਮੈਮੋਰੀ) ਲਈ ਪ੍ਰਤੀ-ਫਰੇਮ ਬਜਟ ਸੈੱਟ ਕਰੋ। ਇਹ ਬਜਟ ਫੀਚਰ ਲਕੜੀ ਦੇ ਨੇੜੇ ਟੰਗੀ ਠੀਕ ਦਿੱਤੇ ਜਾਣ।
ਆਈਸੋਲੇਟ: ਇੱਕ ਘੱਟ ਸਸੀਨ ਜਾਂ ਟੈਸਟ ਵਿੱਚ ਲਾਗਤ ਨੂੰ ਦੁਹਰਾਓ। ਜੇ ਤੁਸੀਂ ਉਸਨੂੰ ਦੁਹਰਾ ਨਹੀਂ ਸਕਦੇ ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕੋਗੇ।
ਓਪਟੀਮਾਈਜ਼: ਇੱਕ ਹੀ ਚੀਜ਼ ਇੱਕ ਵਾਰੀ ਬਦਲੋ। ਕੰਮ ਘਟਾਉਣ ਵਾਲੇ ਬਦਲਾਅ ਪਸੰਦ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ "ਤੇਜ਼ ਬਣਾਉਣ" ਵਾਲੇ।
ਵੈਰੀਫਾਈ: ਮੁੜ-ਪ੍ਰੋਫਾਈਲ ਕਰੋ, ਡੈਲਟਾਸ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਕੁਆਲਿਟੀ ਜਾਂ ਸਹੀਤਾ ਦੀਆਂ ਰਿਗ੍ਰੈਸ਼ਨਜ਼ ਦੀ ਜਾਂਚ ਕਰੋ।
ਦਸਤਾਵੇਜ਼: ਕੀ ਬਦਲਿਆ, ਕਿਉਂ ਇਹ ਮਦਦ ਕਰ ਗਿਆ, ਅਤੇ ਭਵਿੱਖ ਵਿੱਚ ਕਿਸ ਚੀਜ਼ ਦੀ ਭੇਦਭਰਕਾਈ ਕਰਨ ਲਈ ਦਰਜ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਇਹ ਆਦਤਾਂ ਟੀਮ ਵਿੱਚ ਚਲਾਉਣੀਆਂ ਚਾਹੁੰਦੇ ਹੋ, ਚਾਬੀ friction ਘਟਾਉਣਾ ਹੈ: ਤੇਜ਼ ਪ੍ਰਯੋਗ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਹਾਰਨੈੱਸ, ਅਤੇ ਆਸਾਨ ਰੋਲਬੈਕ।
Koder.ai ਇੱਥੇ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਆਂਤਰਿਕ ਟੂਲਿੰਗ ਬਣਾ ਰਹੇ ਹੋ—Engine ਨਹੀਂ। ਇਹ ਇਕ vibe-coding ਪਲੇਟਫਾਰਮ ਹੈ ਜੋ ਅਸਲ, ਐਕਸਪੋਰਟਯੋਗ ਸੋਰਸ ਕੋਡ ਜਨਰੇਟ ਕਰਦਾ ਹੈ (React ਵੈੱਬ ਐਪਸ; Go ਬੈਕਏਂਡ ਨਾਲ PostgreSQL; Flutter ਮੋਬਾਈਲ)। ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਆਂਤਰਿਕ ਡੈਸ਼ਬੋਰਡ ਬਣਾ ਸਕਦੇ ਹੋ ਫਰੇਮ-ਟਾਈਮ ਪਰਸੈਂਟਾਈਲਜ਼, ਰਿਗ੍ਰੈਸ਼ਨ ਇਤਿਹਾਸ, ਅਤੇ "ਪਰਫ ਰਿਵਿਊ" ਚੈਕਲਿਸਟ ਲਈ, ਫਿਰ ਚੈਟ ਦੁਆਰਾ ਜ਼ਰੂਰਤਾਂ ਦੇ ਅਨੁਸਾਰ ਇਟਰੇਟ ਕਰੋ। ਸਨੇਪਸ਼ਾਟ ਅਤੇ ਰੋਲਬੈਕ “ਇੱਕ ਚੀਜ਼ ਬਦਲੋ, ਮੁੜ ਮਾਪੋ” ਲੂਪ ਲਈ ਵਰਤੋਂਯੋਗ ਹਨ।
ਜੇ ਤੁਸੀਂ ਹੋਰ ਅਮਲੀ ਮਾਰਗਦਰਸ਼ਨ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog ਨੂੰ ਵੇਖੋ ਜਾਂ ਦੇਖੋ ਕਿ ਟੀਮਾਂ ਇਹਨੂੰ /pricing ਉੱਤੇ ਕਿਵੇਂ ਅਪਰੇਸ਼ਨਲਾਇਜ਼ ਕਰਦੀਆਂ ਹਨ।
ਫਰੇਮ ਟਾਈਮ ਮਤਲਬ ਹੈ ਹਰ ਫਰੇਮ ਲਈ ਲੱਗਦਾ ਸਮਾਂ ਮਿਲੀਸੈਕਿੰਡ (ms) ਵਿੱਚ, ਅਤੇ ਇਹ ਸਿੱਧਾ ਦਰਸਾਉਂਦਾ ਕਿ CPU/GPU ਨੇ ਕਿੰਨਾ ਕੰਮ ਕੀਤਾ।
ਇੱਕ ਲਕੜੀ ਮੰਨੋ (ਉਦਾਹਰਨ ਲਈ 60 FPS) ਅਤੇ ਇਸਨੂੰ ਸਖਤ ਡੈਡਲਾਈਨ (16.6 ms) ਵਿੱਚ ਬਦਲੋ। ਫਿਰ ਇਸ ਡੈਡਲਾਈਨ ਨੂੰ ਖੁੱਲ੍ਹ ਕੇ ਖਾਸ ਬਜਟਾਂ ਵਿੱਚ ਵੰਡੋ।
ਉਦਾਹਰਨ ਸ਼ੁਰੂਆਤੀ ਵੰਡ:
ਇਹਨਾਂ ਨੂੰ ਉਤਪਾਦ ਦੀਆਂ ਲੋੜਾਂ ਵਜੋਂ ਮੰਨੋ ਅਤੇ ਪਲੇਟਫਾਰਮ, ਰੇਜ਼ੋਲੂਸ਼ਨ, ਥਰਮਲ ਅਤੇ ਇਨਪੁਟ-ਲੈਟੈਂਸੀ ਮੁਤਾਬਕ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਅਨੁਕੂਲ ਕਰੋ।
ਪਹਿਲਾਂ ਆਪਣੀਆਂ ਜਾਂਚਾਂ ਨੂੰ ਰੀਪ੍ਰੋਡਯੂਸਬਲ ਬਨਾਓ, ਫਿਰ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਪ ਕਰੋ।
ਤਾਹਿ ਜਾਣਨ ਤੋਂ ਬਾਅਦ ਹੀ ਫੈਸਲਾ ਕਰੋ ਕਿ ਕੀ ਅਨੁਕੂਲਿਤ ਕਰਨਾ ਹੈ।
ਚੁਸਤ, ਨਿਸ਼ਾਨਦਾਰ ਪ੍ਰਯੋਗ ਕਰੋ ਜੋ ਬਾਦ ਵਿਚ ਸਪਸ਼ਟ ਨਤੀਜੇ ਦਿੰਦੇ ਹਨ:
ਸਿਸਟਮ ਨੂੰ ਮੁੜ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਇਕ ਭਾਰ (ਮਿਲੀਸੈਕਿੰਡ ਵਿੱਚ) ਨਾਮ ਦਿਓ ਜੋ ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ।
ਉਪਭੋਗੀ ਐਵਰਜ ਨਾ ਸਮਝ ਕੇ ਬਦਤਰ ਕਰਦੇ ਹਨ — ਲੋਕ ਹਮੇਸ਼ਾਂ ਸਭ ਤੋਂ ਖਰਾਬ ਪਲ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ।
ਟ੍ਰੈਕ ਕਰੋ:
ਜੋ ਬਿਲਡ ਅਕਸਰ 16.6 ms ਰਹਿੰਦੀ ਹੈ ਪਰ ਕਈ ਵਾਰ 80 ms ਤੱਕ ਚਲਦੀ ਹੈ, ਉਵੇਂ ਅਨਭਵ ਵਿੱਚ ਟੁੱਟਿਆ ਹੋਇਆ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।
ਮਹਿੰਗੇ ਕੰਮ ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਤੇ ਸਥਿਰ ਬਣਾਓ:
ਸਪਾਈਕਾਂ ਨੂੰ ਰਿਕਾਰਡ ਅਤੇ ਵਿਜ਼ੁਅਲਾਇਜ਼ ਕਰੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਦੁਹਰਾ ਕੇ ਠੀਕ ਕਰ ਸਕੋ, ਨਾ ਕਿ ਉਮੀਦ ਕਰੋ ਕਿ ਉਹ ਖਤਮ ਹੋ ਜਾਣਗੇ।
ਫੈਸਲਿਆਂ ਨੂੰ ਖੁੱਲ੍ਹ ਕੇ ਨਾਮ ਦਿਓ: ਕੀ ਅਸੀਂ ਕੀ ਖਰੀਦ ਰਹੇ ਹਾਂ, ਕੀ ਭੁਗਤਾਣ ਕਰ ਰਹੇ ਹਾਂ, ਅਤੇ ਕਿਸ ਨੂੰ ਅੰਤਰ ਮਹਿਸੂਸ ਹੋਏਗਾ।
ਆਮ ਅਕਸੀਜ਼:
ਜੇ ਪਰੋਗ੍ਰਾਮ ਸਹੀ ਨ ਹੋਵੇ ਤਾਂ ਪਰਫਾਰਮੈਂਸ ਕੰਮ ਮੁਸ਼ਕਿਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਕਈ ਵਾਰ ‘ਆਪਟੀਮਾਈਜ਼ੇਸ਼ਨ’ ਦਰਅਸਲ ਸਹੀਤਾ ਬੱਗਾਂ ਦੇ ਪਿੱਛੇ ਦੌੜਣਾ ਹੁੰਦੀ ਹੈ।
ਅਮਲੀ ਕਦਮ:
ਜਦ ਤਕ ਰਨ-ਟੂ-ਰਨ ਵਿਹਾਰ ਵੱਖਰਾ ਰਹੇਗਾ, ਤੁਸੀਂ ਪ੍ਰੋਫਾਈਲਾਂ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕੋਗੇ।
ਮਸ਼ੀਨ ਨੂੰ ਸਮਝੋ: CPU/GPU ਲਈ ਡੇਟਾ ਪੇਸ਼ ਕਰਨ ਦਾ ਸਹੀ ਢੰਗ ਜ਼ਰੂਰੀ ਹੈ।
ਢੰਗ:
ਇਹ ਅਕਸਰ ਅੰਦਰੂਨੀ ਲੂਪ ਨੂੰ ਠੀਕ ਕਰਨ ਨਾਲੋਂ ਵੱਡਾ ਨਤੀਜਾ ਦਿੰਦਾ ਹੈ।
ਪਰਫਾਰਮੈਂਸ ਰਿਗ੍ਰੈਸ਼ਨਸ ਟੈਸਟਿੰਗ ਰੀਲ-ਟਾਈਮ ਸ਼ਿੱਪਿੰਗ ਲਈ ਜ਼ਰੂਰੀ ਹੈ; ਇਸਨੂੰ ਆਸਾਨ ਅਤੇ ਨਿਯਮਤ ਬਣਾਓ।
ਸਧਾਰਨ ਪ੍ਰਵਾਹ:
ਟ੍ਰੈਕ ਕਰਨ ਲਾਇਕ ਮੈਟ੍ਰਿਕਸ:
ਬਦਲਾਅ ਦੇ ਗਿਣਤੀਕृत ਪ੍ਰਭਾਵ ਦਿਖਾਓ: “ਇਸ ਨਾਲ 0.4 ms GPU ਤੇ 80 MB VRAM ਵੱਧੇਗਾ” — ਇਹ ਬੇਹਤਰ ਹੈ “ਇਹ ਵਧੀਆ ਲੱਗਦਾ ਹੈ” ਕਹਿਣ ਨਾਲ।
ਰਿਗ੍ਰੈਸ਼ਨ ਮਿਲਣ 'ਤੇ: ਬਾਇਸੈਕਟ ਕਰੋ, ਮਾਲਿਕ ਤੈਅ ਕਰੋ ਅਤੇ ਜੇ ਰਿਲੀਜ਼ ਰੁੱਖਦੀ ਹੈ ਤਾਂ ਫੱਟੇ-ਫੱਟ ਰਿਵਰਟ ਕਰੋ।