ਪ੍ਰਤੀਬਿੰਬ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਬਾਰੇ ਅਸਫਲ ਲੇਖ

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

ਮੈਂ ਇਸ ਲੇਖ ਦੇ ਪ੍ਰਭਾਵ ਹੇਠ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ: ਪ੍ਰਤੀਬਿੰਬ ਹੌਲੀ ਕਿਉਂ ਹੈ

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

ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕਿ ਮੈਂ ਹਮੇਸ਼ਾਂ ਪ੍ਰਤੀਬਿੰਬ ਦੀ ਗਤੀ ਬਾਰੇ ਇੱਕ ਸਮਾਨ ਰਾਇ ਰੱਖਦਾ ਹਾਂ, ਮੇਰਾ ਖਾਸ ਤੌਰ 'ਤੇ ਲੇਖਕ ਦੇ ਸਿੱਟਿਆਂ 'ਤੇ ਸਵਾਲ ਕਰਨ ਦਾ ਇਰਾਦਾ ਨਹੀਂ ਸੀ।

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

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

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

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

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

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

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

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

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

ਇਸ ਵਿੱਚ ਤਰਕ ਹੈ। ਆਮ ਸਮਝ ਸਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਜੇ ਕੁਝ ਸੰਕਲਿਤ ਅਤੇ ਕੈਸ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਹ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ.

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

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

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

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

ਅਸੀਂ ਲਾਗੂ ਕਰਦੇ ਹਾਂ, ਟੈਸਟ ਬਣਾਉਂਦੇ ਹਾਂ. ਕੰਮ ਕਰਦਾ ਹੈ।

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

ਤਰਕ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੈ: ਟੈਂਪਲੇਟ ਵਿਧੀ ਮੂਲ ਪਾਰਸਰ ਤਰਕ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਜੋੜੇ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ। LINQ ਪਰਤ ਪਾਰਸਰ ਹੈ ਅਤੇ ਹਾਈਡ੍ਰੇਟਰ ਦਾ ਮੂਲ ਤਰਕ ਹੈ, ਜੋ ਕਿ ਡੇਟਾਬੇਸ ਸੰਦਰਭ ਲਈ ਬੇਨਤੀ ਕਰਦਾ ਹੈ ਅਤੇ ਪਾਰਸਰ ਦੇ ਜੋੜਿਆਂ ਨਾਲ ਕੁੰਜੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰਦਾ ਹੈ (ਇਹਨਾਂ ਫੰਕਸ਼ਨਾਂ ਲਈ ਤੁਲਨਾ ਲਈ LINQ ਤੋਂ ਬਿਨਾਂ ਕੋਡ ਹੈ)। ਅੱਗੇ, ਜੋੜਿਆਂ ਨੂੰ ਮੁੱਖ ਹਾਈਡਰੇਸ਼ਨ ਵਿਧੀ ਵਿੱਚ ਪਾਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਜੋੜਿਆਂ ਦੇ ਮੁੱਲਾਂ ਨੂੰ ਇਕਾਈ ਦੇ ਅਨੁਸਾਰੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ ਸੈੱਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

“ਫਾਸਟ” (ਬੈਂਚਮਾਰਕ ਵਿੱਚ ਪ੍ਰੀਫਿਕਸ ਫਾਸਟ):

 protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var setterMapItem in _proprtySettersMap)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == setterMapItem.Key);
                setterMapItem.Value(contact, correlation?.Value);
            }
            return contact;
        }

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ, ਸੇਟਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਾਲਾ ਇੱਕ ਸਥਿਰ ਸੰਗ੍ਰਹਿ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ - ਕੰਪਾਇਲਡ ਲੈਂਬਡਾਸ ਜੋ ਸੇਟਰ ਇਕਾਈ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ। ਹੇਠਾਂ ਦਿੱਤੇ ਕੋਡ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ:

        static FastContactHydrator()
        {
            var type = typeof(Contact);
            foreach (var property in type.GetProperties())
            {
                _proprtySettersMap[property.Name] = GetSetterAction(property);
            }
        }

        private static Action<Contact, string> GetSetterAction(PropertyInfo property)
        {
            var setterInfo = property.GetSetMethod();
            var paramValueOriginal = Expression.Parameter(property.PropertyType, "value");
            var paramEntity = Expression.Parameter(typeof(Contact), "entity");
            var setterExp = Expression.Call(paramEntity, setterInfo, paramValueOriginal).Reduce();
            
            var lambda = (Expression<Action<Contact, string>>)Expression.Lambda(setterExp, paramEntity, paramValueOriginal);

            return lambda.Compile();
        }

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

“ਹੌਲੀ” (ਬੈਂਚਮਾਰਕ ਵਿੱਚ ਅਗੇਤਰ ਹੌਲੀ):

        protected override Contact GetContact(PropertyToValueCorrelation[] correlations)
        {
            var contact = new Contact();
            foreach (var property in _properties)
            {
                var correlation = correlations.FirstOrDefault(x => x.PropertyName == property.Name);
                if (correlation?.Value == null)
                    continue;

                property.SetValue(contact, correlation.Value);
            }
            return contact;
        }

ਇੱਥੇ ਅਸੀਂ ਤੁਰੰਤ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੇ ਹਾਂ ਅਤੇ SetValue ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰਦੇ ਹਾਂ।

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

ਹੁਣ ਆਓ ਬੈਂਚਮਾਰਕਡੌਟਨੈੱਟ ਨੂੰ ਲੈ ਕੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੀਏ। ਅਤੇ ਅਚਾਨਕ... (ਵਿਗਾੜਨ ਵਾਲਾ - ਇਹ ਸਹੀ ਨਤੀਜਾ ਨਹੀਂ ਹੈ, ਵੇਰਵੇ ਹੇਠਾਂ ਦਿੱਤੇ ਗਏ ਹਨ)

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

ਨਵੀਨਤਮ ਕੀਤਾ

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

ਇੱਥੇ ਰੀਟੈਸਟ ਦਾ ਨਤੀਜਾ ਹੈ:

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

ਬੈਂਚਮਾਰਕ ਕੋਡ ਇੱਥੇ ਉਪਲਬਧ ਹੈ। ਕੋਈ ਵੀ ਮੇਰੇ ਸ਼ਬਦਾਂ ਦੀ ਦੋ ਵਾਰ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ:
ਹੈਬਰਾ ਰਿਫਲੈਕਸ਼ਨ ਟੈਸਟ

PS: ਟੈਸਟਾਂ ਵਿੱਚ ਕੋਡ IoC ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਬੈਂਚਮਾਰਕ ਵਿੱਚ ਇਹ ਇੱਕ ਸਪਸ਼ਟ ਨਿਰਮਾਣ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਤੱਥ ਇਹ ਹੈ ਕਿ ਅੰਤਮ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਮੈਂ ਉਹਨਾਂ ਸਾਰੇ ਕਾਰਕਾਂ ਨੂੰ ਕੱਟ ਦਿੱਤਾ ਜੋ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਰੌਲਾ ਪਾ ਸਕਦੇ ਹਨ.

PPS: ਉਪਭੋਗਤਾ ਦਾ ਧੰਨਵਾਦ ਦਮਿੱਤਰੀ ਟਿਖੋਨੋਵ @0x1000000 Moq ਸਥਾਪਤ ਕਰਨ ਵਿੱਚ ਮੇਰੀ ਗਲਤੀ ਨੂੰ ਖੋਜਣ ਲਈ, ਜਿਸ ਨੇ ਪਹਿਲੇ ਮਾਪਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ। ਜੇ ਕਿਸੇ ਪਾਠਕ ਕੋਲ ਕਾਫੀ ਕਰਮ ਹੋਵੇ ਤਾਂ like ਕਰੋ ਜੀ। ਆਦਮੀ ਰੁਕ ਗਿਆ, ਆਦਮੀ ਨੇ ਪੜ੍ਹਿਆ, ਆਦਮੀ ਨੇ ਦੋ ਵਾਰ ਜਾਂਚ ਕੀਤੀ ਅਤੇ ਗਲਤੀ ਦੱਸੀ। ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਸਨਮਾਨ ਅਤੇ ਹਮਦਰਦੀ ਦੇ ਯੋਗ ਹੈ।

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

ਸਰੋਤ: www.habr.com