ಪ್ರತಿಬಿಂಬವನ್ನು ವೇಗಗೊಳಿಸುವ ಕುರಿತು ವಿಫಲ ಲೇಖನ

ನಾನು ತಕ್ಷಣ ಲೇಖನದ ಶೀರ್ಷಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತೇನೆ. ಸರಳವಾದ ಆದರೆ ವಾಸ್ತವಿಕ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಪ್ರತಿಬಿಂಬದ ಬಳಕೆಯನ್ನು ಹೇಗೆ ವೇಗಗೊಳಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಉತ್ತಮ, ವಿಶ್ವಾಸಾರ್ಹ ಸಲಹೆಯನ್ನು ನೀಡುವುದು ಮೂಲ ಯೋಜನೆಯಾಗಿದೆ, ಆದರೆ ಮಾನದಂಡದ ಸಮಯದಲ್ಲಿ ಪ್ರತಿಫಲನವು ನಾನು ಯೋಚಿಸಿದಷ್ಟು ನಿಧಾನವಾಗಿರುವುದಿಲ್ಲ, LINQ ನನ್ನ ದುಃಸ್ವಪ್ನಗಳಿಗಿಂತ ನಿಧಾನವಾಗಿರುತ್ತದೆ. ಆದರೆ ಕೊನೆಯಲ್ಲಿ ನಾನು ಅಳತೆಗಳಲ್ಲಿ ತಪ್ಪು ಮಾಡಿದೆ ಎಂದು ಬದಲಾಯಿತು ... ಈ ಜೀವನ ಕಥೆಯ ವಿವರಗಳು ಕಟ್ ಮತ್ತು ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿವೆ. ಉದಾಹರಣೆಯು ಸಾಕಷ್ಟು ಸಾಮಾನ್ಯವಾಗಿದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಉದ್ಯಮದಲ್ಲಿ ಮಾಡುವಂತೆ ತಾತ್ವಿಕವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಿರುವುದರಿಂದ, ಇದು ನನಗೆ ತೋರುತ್ತಿರುವಂತೆ, ಜೀವನದ ಪ್ರದರ್ಶನವು ಸಾಕಷ್ಟು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ: ಲೇಖನದ ಮುಖ್ಯ ವಿಷಯದ ವೇಗದ ಮೇಲೆ ಪರಿಣಾಮ ಬಾಹ್ಯ ತರ್ಕದಿಂದಾಗಿ ಗಮನಿಸುವುದಿಲ್ಲ: Moq, Autofac, EF ಕೋರ್ ಮತ್ತು ಇತರ "ಪಟ್ಟಿಗಳು".

ಈ ಲೇಖನದ ಪ್ರಭಾವದಡಿಯಲ್ಲಿ ನಾನು ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದೆ: ಪ್ರತಿಫಲನ ಏಕೆ ನಿಧಾನವಾಗಿದೆ

ನೀವು ನೋಡುವಂತೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೆಚ್ಚು ವೇಗಗೊಳಿಸಲು ಉತ್ತಮ ಮಾರ್ಗವಾಗಿ ಪ್ರತಿಫಲನ ಪ್ರಕಾರದ ವಿಧಾನಗಳನ್ನು ನೇರವಾಗಿ ಕರೆಯುವ ಬದಲು ಸಂಕಲಿಸಿದ ಪ್ರತಿನಿಧಿಗಳನ್ನು ಬಳಸುವುದನ್ನು ಲೇಖಕರು ಸೂಚಿಸುತ್ತಾರೆ. ಸಹಜವಾಗಿ, ಐಎಲ್ ಹೊರಸೂಸುವಿಕೆ ಇದೆ, ಆದರೆ ನಾನು ಅದನ್ನು ತಪ್ಪಿಸಲು ಬಯಸುತ್ತೇನೆ, ಏಕೆಂದರೆ ಇದು ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸಲು ಹೆಚ್ಚು ಶ್ರಮದಾಯಕ ಮಾರ್ಗವಾಗಿದೆ, ಇದು ದೋಷಗಳಿಂದ ತುಂಬಿದೆ.

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

ಎಂಟರ್‌ಪ್ರೈಸ್‌ನಲ್ಲಿ ಪ್ರತಿಬಿಂಬದ ನಿಷ್ಕಪಟ ಬಳಕೆಯನ್ನು ನಾನು ಆಗಾಗ್ಗೆ ಎದುರಿಸುತ್ತೇನೆ. ಪ್ರಕಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ. ಆಸ್ತಿ ಬಗ್ಗೆ ಮಾಹಿತಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ. SetValue ವಿಧಾನವನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಎಲ್ಲರೂ ಸಂತೋಷಪಡುತ್ತಾರೆ. ಗುರಿ ಕ್ಷೇತ್ರಕ್ಕೆ ಮೌಲ್ಯ ಬಂದಿದೆ, ಎಲ್ಲರೂ ಸಂತೋಷವಾಗಿದ್ದಾರೆ. ತುಂಬಾ ಸ್ಮಾರ್ಟ್ ಜನರು - ಹಿರಿಯರು ಮತ್ತು ತಂಡದ ನಾಯಕರು - ಒಂದು ರೀತಿಯ ಮತ್ತೊಂದು ರೀತಿಯ "ಸಾರ್ವತ್ರಿಕ" ಮ್ಯಾಪರ್‌ಗಳನ್ನು ಅಂತಹ ನಿಷ್ಕಪಟ ಅನುಷ್ಠಾನದ ಆಧಾರದ ಮೇಲೆ ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ತಮ್ಮ ವಿಸ್ತರಣೆಗಳನ್ನು ಬರೆಯಿರಿ. ಸಾರವು ಸಾಮಾನ್ಯವಾಗಿ ಇದು: ನಾವು ಎಲ್ಲಾ ಕ್ಷೇತ್ರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ, ಎಲ್ಲಾ ಗುಣಲಕ್ಷಣಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ, ಅವುಗಳ ಮೇಲೆ ಪುನರಾವರ್ತಿಸುತ್ತೇವೆ: ಪ್ರಕಾರದ ಸದಸ್ಯರ ಹೆಸರುಗಳು ಹೊಂದಾಣಿಕೆಯಾದರೆ, ನಾವು 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 ಅನ್ನು ಕರೆಯುತ್ತೇವೆ.

ಸ್ಪಷ್ಟತೆಗಾಗಿ ಮತ್ತು ಉಲ್ಲೇಖವಾಗಿ, ನಾನು ನಿಷ್ಕಪಟ ವಿಧಾನವನ್ನು ಜಾರಿಗೆ ತಂದಿದ್ದೇನೆ ಅದು ಅವುಗಳ ಪರಸ್ಪರ ಸಂಬಂಧದ ಜೋಡಿಗಳ ಮೌಲ್ಯಗಳನ್ನು ನೇರವಾಗಿ ಅಸ್ತಿತ್ವದ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಬರೆಯುತ್ತದೆ. ಪೂರ್ವಪ್ರತ್ಯಯ - ಕೈಪಿಡಿ.

ಈಗ ನಾವು BenchmarkDotNet ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪರೀಕ್ಷಿಸೋಣ. ಮತ್ತು ಇದ್ದಕ್ಕಿದ್ದಂತೆ... (ಸ್ಪಾಯ್ಲರ್ - ಇದು ಸರಿಯಾದ ಫಲಿತಾಂಶವಲ್ಲ, ವಿವರಗಳು ಕೆಳಗಿವೆ)

ನಾವು ಇಲ್ಲಿ ಏನು ನೋಡುತ್ತೇವೆ? ವೇಗದ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ವಿಜಯಶಾಲಿಯಾಗಿ ಹೊಂದಿರುವ ವಿಧಾನಗಳು ನಿಧಾನ ಪೂರ್ವಪ್ರತ್ಯಯದ ವಿಧಾನಗಳಿಗಿಂತ ಬಹುತೇಕ ಎಲ್ಲಾ ಪಾಸ್‌ಗಳಲ್ಲಿ ನಿಧಾನವಾಗಿರುತ್ತವೆ. ಹಂಚಿಕೆ ಮತ್ತು ಕೆಲಸದ ವೇಗ ಎರಡಕ್ಕೂ ಇದು ನಿಜ. ಮತ್ತೊಂದೆಡೆ, ಸಾಧ್ಯವಿರುವಲ್ಲೆಲ್ಲಾ ಇದಕ್ಕಾಗಿ ಉದ್ದೇಶಿಸಲಾದ LINQ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಮ್ಯಾಪಿಂಗ್‌ನ ಸುಂದರವಾದ ಮತ್ತು ಸೊಗಸಾದ ಅನುಷ್ಠಾನವು ಉತ್ಪಾದಕತೆಯನ್ನು ಬಹಳವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ವ್ಯತ್ಯಾಸವು ಕ್ರಮದಲ್ಲಿದೆ. ವಿಭಿನ್ನ ಸಂಖ್ಯೆಯ ಪಾಸ್‌ಗಳೊಂದಿಗೆ ಪ್ರವೃತ್ತಿಯು ಬದಲಾಗುವುದಿಲ್ಲ. ಪ್ರಮಾಣದಲ್ಲಿ ಮಾತ್ರ ವ್ಯತ್ಯಾಸವಿದೆ. LINQ ನೊಂದಿಗೆ ಇದು 4 - 200 ಪಟ್ಟು ನಿಧಾನವಾಗಿರುತ್ತದೆ, ಸರಿಸುಮಾರು ಅದೇ ಪ್ರಮಾಣದಲ್ಲಿ ಹೆಚ್ಚು ಕಸವಿದೆ.

ಅಪ್ಡೇಟ್ಗೊಳಿಸಲಾಗಿದೆ

ನಾನು ನನ್ನ ಕಣ್ಣುಗಳನ್ನು ನಂಬಲಿಲ್ಲ, ಆದರೆ ಮುಖ್ಯವಾಗಿ, ನಮ್ಮ ಸಹೋದ್ಯೋಗಿ ನನ್ನ ಕಣ್ಣುಗಳನ್ನು ಅಥವಾ ನನ್ನ ಕೋಡ್ ಅನ್ನು ನಂಬಲಿಲ್ಲ - ಡಿಮಿಟ್ರಿ ಟಿಖೋನೊವ್ 0x1000000. ನನ್ನ ಪರಿಹಾರವನ್ನು ಎರಡು ಬಾರಿ ಪರಿಶೀಲಿಸಿದ ನಂತರ, ಅವರು ಅದ್ಭುತವಾಗಿ ಕಂಡುಹಿಡಿದರು ಮತ್ತು ಅನುಷ್ಠಾನದಲ್ಲಿನ ಹಲವಾರು ಬದಲಾವಣೆಗಳಿಂದಾಗಿ ನಾನು ತಪ್ಪಿಸಿಕೊಂಡ ದೋಷವನ್ನು ತೋರಿಸಿದರು, ಪ್ರಾರಂಭದಿಂದ ಅಂತಿಮ. Moq ಸೆಟಪ್‌ನಲ್ಲಿ ಕಂಡುಬಂದ ದೋಷವನ್ನು ಸರಿಪಡಿಸಿದ ನಂತರ, ಎಲ್ಲಾ ಫಲಿತಾಂಶಗಳು ಸ್ಥಳದಲ್ಲಿ ಬಿದ್ದವು. ಮರುಪರೀಕ್ಷೆಯ ಫಲಿತಾಂಶಗಳ ಪ್ರಕಾರ, ಮುಖ್ಯ ಪ್ರವೃತ್ತಿಯು ಬದಲಾಗುವುದಿಲ್ಲ - LINQ ಇನ್ನೂ ಪ್ರತಿಬಿಂಬಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಅಭಿವ್ಯಕ್ತಿ ಸಂಕಲನದೊಂದಿಗೆ ಕೆಲಸವು ವ್ಯರ್ಥವಾಗಿ ಮಾಡದಿರುವುದು ಸಂತೋಷವಾಗಿದೆ, ಮತ್ತು ಫಲಿತಾಂಶವು ಹಂಚಿಕೆ ಮತ್ತು ಮರಣದಂಡನೆಯ ಸಮಯದಲ್ಲಿ ಗೋಚರಿಸುತ್ತದೆ. ಮೊದಲ ಉಡಾವಣೆ, ಸ್ಥಿರ ಕ್ಷೇತ್ರಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, "ವೇಗದ" ವಿಧಾನಕ್ಕೆ ಸ್ವಾಭಾವಿಕವಾಗಿ ನಿಧಾನವಾಗಿರುತ್ತದೆ, ಆದರೆ ನಂತರ ಪರಿಸ್ಥಿತಿ ಬದಲಾಗುತ್ತದೆ.

ಮರು ಪರೀಕ್ಷೆಯ ಫಲಿತಾಂಶ ಇಲ್ಲಿದೆ:

ತೀರ್ಮಾನ: ಎಂಟರ್‌ಪ್ರೈಸ್‌ನಲ್ಲಿ ಪ್ರತಿಫಲನವನ್ನು ಬಳಸುವಾಗ, ನಿರ್ದಿಷ್ಟ ತಂತ್ರಗಳನ್ನು ಆಶ್ರಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ - LINQ ಉತ್ಪಾದಕತೆಯನ್ನು ಹೆಚ್ಚು ತಿನ್ನುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಆಪ್ಟಿಮೈಸೇಶನ್ ಅಗತ್ಯವಿರುವ ಹೆಚ್ಚಿನ-ಲೋಡ್ ವಿಧಾನಗಳಲ್ಲಿ, ನೀವು ಪ್ರತಿಬಿಂಬವನ್ನು ಇನಿಶಿಯಲೈಜರ್‌ಗಳು ಮತ್ತು ಪ್ರತಿನಿಧಿ ಕಂಪೈಲರ್‌ಗಳ ರೂಪದಲ್ಲಿ ಉಳಿಸಬಹುದು, ಅದು ನಂತರ "ವೇಗದ" ತರ್ಕವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಈ ರೀತಿಯಾಗಿ ನೀವು ಪ್ರತಿಬಿಂಬದ ನಮ್ಯತೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ವೇಗ ಎರಡನ್ನೂ ನಿರ್ವಹಿಸಬಹುದು.

ಬೆಂಚ್ಮಾರ್ಕ್ ಕೋಡ್ ಇಲ್ಲಿ ಲಭ್ಯವಿದೆ. ಯಾರಾದರೂ ನನ್ನ ಪದಗಳನ್ನು ಎರಡು ಬಾರಿ ಪರಿಶೀಲಿಸಬಹುದು:
ಹಬ್ರಾ ರಿಫ್ಲೆಕ್ಷನ್ ಪರೀಕ್ಷೆಗಳು

PS: ಪರೀಕ್ಷೆಗಳಲ್ಲಿನ ಕೋಡ್ IoC ಅನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಮಾನದಂಡಗಳಲ್ಲಿ ಇದು ಸ್ಪಷ್ಟವಾದ ರಚನೆಯನ್ನು ಬಳಸುತ್ತದೆ. ವಾಸ್ತವವೆಂದರೆ ಅಂತಿಮ ಅನುಷ್ಠಾನದಲ್ಲಿ ನಾನು ಕಾರ್ಯಕ್ಷಮತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಗದ್ದಲ ಮಾಡುವ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಕತ್ತರಿಸಿದ್ದೇನೆ.

PPS: ಬಳಕೆದಾರರಿಗೆ ಧನ್ಯವಾದಗಳು ಡಿಮಿಟ್ರಿ ಟಿಖೋನೊವ್ @0x1000000 Moq ಅನ್ನು ಹೊಂದಿಸುವಲ್ಲಿ ನನ್ನ ದೋಷವನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದಕ್ಕಾಗಿ, ಇದು ಮೊದಲ ಅಳತೆಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಿತು. ಓದುಗರಲ್ಲಿ ಯಾರಾದರೂ ಸಾಕಷ್ಟು ಕರ್ಮವನ್ನು ಹೊಂದಿದ್ದರೆ, ದಯವಿಟ್ಟು ಅದನ್ನು ಲೈಕ್ ಮಾಡಿ. ಮನುಷ್ಯ ನಿಲ್ಲಿಸಿದನು, ಮನುಷ್ಯ ಓದಿದನು, ಮನುಷ್ಯ ಎರಡು ಬಾರಿ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ತಪ್ಪನ್ನು ತೋರಿಸಿದನು. ಇದು ಗೌರವ ಮತ್ತು ಸಹಾನುಭೂತಿಗೆ ಯೋಗ್ಯವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

PPPS: ಶೈಲಿ ಮತ್ತು ವಿನ್ಯಾಸದ ಕೆಳಭಾಗಕ್ಕೆ ಬಂದ ನಿಖರವಾದ ಓದುಗರಿಗೆ ಧನ್ಯವಾದಗಳು. ನಾನು ಏಕರೂಪತೆ ಮತ್ತು ಅನುಕೂಲಕ್ಕಾಗಿ ಇದ್ದೇನೆ. ಪ್ರಸ್ತುತಿಯ ರಾಜತಾಂತ್ರಿಕತೆಯು ಅಪೇಕ್ಷಿತವಾಗಿರುವುದನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಆದರೆ ನಾನು ಟೀಕೆಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡೆ. ನಾನು ಉತ್ಕ್ಷೇಪಕವನ್ನು ಕೇಳುತ್ತೇನೆ.

ಮೂಲ: www.habr.com