ಆಬ್ಜೆಕ್ಟ್ ಹೈಡ್ರೇಶನ್ (Object hydration) ನೀವು ಅದನ್ನು ಅಳೆಯುವವರೆಗೆ ಒಂದು ಪರಿಹರಿಸಲ್ಪಟ್ಟ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ. ನೀವು ಡೇಟಾಬೇಸ್‌ನಿಂದ ಒಂದು ಸಾಲನ್ನು (row) ಪಡೆಯುತ್ತೀರಿ, ಆ ಅರೇಯನ್ನು (array) ಒಂದು ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ಮ್ಯಾಪ್ ಮಾಡುತ್ತೀರಿ ಮತ್ತು ಮುಂದುವರಿಯುತ್ತೀರಿ. ನಮ್ಮಲ್ಲಿ ಹೆಚ್ಚಿನವರು ಇದನ್ನು ಪ್ಲಂಬಿಂಗ್‌ನಂತೆ ಪರಿಗಣಿಸುತ್ತೇವೆ—ಕಣ್ಣಿಗೆ ಕಾಣದ, ಅಷ್ಟೇನೂ ಆಕರ್ಷಕವಲ್ಲದ ಮತ್ತು ಸಾಕಷ್ಟು ವೇಗವಾಗಿದೆ ಎಂದು ಭಾವಿಸುವ ಕೆಲಸ. ನಂತರ ಒಂದು ದಿನ ನೀವು ಬ್ಯಾಚ್ ಜಾಬ್ ಅಥವಾ ಕ್ಯೂ ವರ್ಕರ್ ಅನ್ನು ಪ್ರೊಫೈಲ್ ಮಾಡಿದಾಗ, ಸಿಪಿಯು (CPU) ಸಮಯದ ಒಂದು ದೊಡ್ಡ ಭಾಗ ಮ್ಯಾಪ್ಪರ್‌ಗೆ ವ್ಯರ್ಥವಾಗುತ್ತಿರುವುದನ್ನು ಗಮನಿಸುತ್ತೀರಿ. ಆ ಅರಿವೇ HydraType ಗೆ ಕಾರಣವಾಯಿತು, ಇದು ಒಂದು ಕಠಿಣ ನಿಯಮದ ಸುತ್ತ ನಿರ್ಮಿಸಲ್ಪಟ್ಟ ಹೈಡ್ರೇಟರ್ ಆಗಿದೆ: ಒಂದು ಕ್ಲಾಸ್ ತನ್ನ ಪ್ರಾಪರ್ಟಿಗಳು ಬಳಸದ ಫೀಚರ್‌ಗಳಿಗಾಗಿ ಎಂದಿಗೂ ಬೆಲೆ ತೆರಬಾರದು.

ಒಂದು ಫೀಲ್ಡ್ ಯಾವುದೇ ರೂಪಾಂತರದ ಅಗತ್ಯವಿಲ್ಲದ ಸಾಮಾನ್ಯ ಸ್ಟ್ರಿಂಗ್ ಆಗಿದ್ದರೆ, ಜನರೇಟ್ ಆದ ಕೋಡ್ ಒಬ್ಬ ಮನುಷ್ಯ ಕೈಯಾರೆ ಬರೆದಂತಿರಬೇಕು. ನೇರ ಅಸೈನ್‌ಮೆಂಟ್ (Direct assignment). ಯಾವುದೇ ಲೂಪ್‌ಗಳು, ಪೈಪ್‌ಲೈನ್‌ಗಳು ಅಥವಾ ರಿಫ್ಲೆಕ್ಷನ್ ಇಲ್ಲದೆ.

ಹೈಡ್ರೇಶನ್ ವಾಸ್ತವವಾಗಿ ಎಷ್ಟು ವೆಚ್ಚ ಮಾಡುತ್ತದೆ

ಮೊದಲ ನೋಟಕ್ಕೆ, ['name' => 'Alice', 'age' => 30] ಅನ್ನು User ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ಪರಿವರ್ತಿಸುವುದು ಬಹಳ ಸರಳವಾಗಿ ಕಾಣುತ್ತದೆ. ಆದರೆ ನೀವು ನಮ್ಯತೆ (flexibility) ಬಯಸಿದಾಗ ತೊಂದರೆ ಶುರುವಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ ಹೈಡ್ರೇಟರ್‌ಗಳು ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಕ್ಲಾಸ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ರಿಫ್ಲೆಕ್ಷನ್ (reflection) ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತವೆ. ಅವು ಮೆಟಾಡೇಟಾ ಮ್ಯಾಪ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತವೆ, ಟೈಪ್ ಕೋಯರ್ಶನ್ (type coercion) ಮಾಡಿಸುತ್ತವೆ ಮತ್ತು ನೆಸ್ಟೆಡ್ ಆಬ್ಜೆಕ್ಟ್ ಗ್ರಾಫ್‌ಗಳನ್ನು ಪರಿಹರಿಸುತ್ತವೆ. ಅವುಗಳಿಗೆ ಪೈಪ್‌ಲೈನ್‌ಗಳೆಂದರೆ ತುಂಬಾ ಇಷ್ಟ. ಪ್ರತಿ ಮೌಲ್ಯವು ಮ್ಯುಟೇಟರ್‌ಗಳು, ಅಸರ್‌ಷನ್‌ಗಳು ಮತ್ತು ಟ್ರಾನ್ಸ್‌ಫಾರ್ಮರ್‌ಗಳ ಸರಣಿಯ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ, ಆ ಸರಣಿಯು ಖಾಲಿ ಇದ್ದರೂ ಸಹ. ಲೂಪ್ ರಚನೆಯು ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ಹೆಚ್ಚಿನ ಹೊರೆಯನ್ನು (overhead) ಸೇರಿಸುತ್ತದೆ.

ಕೆಲವು ಡಜನ್ ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ಪಡೆದರೆ ನೀವು ಇದನ್ನು ಎಂದಿಗೂ ಗಮನಿಸುವುದಿಲ್ಲ. ಆದರೆ ಆಧುನಿಕ PHP ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಸಾವಿರಾರು ಕ್ಯೂ ಮೆಸೇಜ್‌ಗಳನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡುತ್ತವೆ, ಬೃಹತ್ CSV ಸೆಟ್‌ಗಳನ್ನು ಇಂಪೋರ್ಟ್ ಮಾಡುತ್ತವೆ ಅಥವಾ Elasticsearch ನಿಂದ ಆಳವಾದ ರಿಸಲ್ಟ್ ಸೆಟ್‌ಗಳನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡುತ್ತವೆ. ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಪ್ರತಿ ಫೀಲ್ಡ್‌ಗೆ ಕೇವಲ ಕೆಲವು ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುವ ಮ್ಯಾಪ್ಪರ್ ನಿಜವಾದ ಅಡಚಣೆಯಾಗುತ್ತದೆ (bottleneck). ಎಂಟು ಫೀಲ್ಡ್‌ಗಳಿರುವ ಸಾವಿರ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ನೀವು ಅನುಭವಿಸುವ ತೆರಿಗೆಯಂತೆ (tax) ಮಲ್ಟಿಪ್ಲೈ ಆಗುತ್ತವೆ.

ಶೂನ್ಯ-ಓವರ್‌ಹೆಡ್ ತತ್ವ (The Zero-Overhead Philosophy)

HydraType ಹಿಂದಿರುವ ಮುಖ್ಯ ಕಲ್ಪನೆಯೆಂದರೆ ಫೀಚರ್ ಐಸೊಲೇಶನ್ (feature isolation). ಟೈಪ್ ಕನ್ವರ್ಷನ್, ನೆಸ್ಟೆಡ್ ಆಬ್ಜೆಕ್ಟ್ ಹೈಡ್ರೇಶನ್ ಮತ್ತು ಅಸರ್‌ಷನ್‌ಗಳು ಎಲ್ಲವನ್ನೂ ಬೆಂಬಲಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಕಡ್ಡಾಯವಲ್ಲ. ಒಂದು ಪ್ರಾಪರ್ಟಿಗೆ ಅರೇಯಿಂದ ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ನೇರ ಕಾಪಿ ಮಾತ್ರ ಬೇಕಾದಲ್ಲಿ, ಜನರೇಟ್ ಆದ ರೈಟರ್ (writer) ಕೇವಲ ಅಷ್ಟನ್ನೇ ಒಳಗೊಂಡಿರುತ್ತದೆ. ಸಾಮಾನ್ಯ ಸ್ಕೇಲರ್ ಫೀಲ್ಡ್ ಅಗತ್ಯವಿಲ್ಲದ ವ್ಯಾಲಿಡೇಟರ್‌ಗಳ ಹಿಂದೆ ಕಾಯುವಂತೆ ಮಾಡುವ ಯಾವುದೇ ಹಂಚಿಕೆಯ ಪೈಪ್‌ಲೈನ್ ಇಲ್ಲ.

ಇದು ಕೇಳಿದಷ್ಟು ಸುಲಭವಲ್ಲ. ಅನೇಕ ಲೈಬ್ರರಿಗಳು ಕೋಡ್ ಬೇಸ್ ಅನ್ನು ಚಿಕ್ಕದಾಗಿ ಮತ್ತು ಏಕರೂಪವಾಗಿಡಲು ಪ್ರತಿ ಫೀಲ್ಡ್‌ಗೆ ಒಂದೇ ಎಕ್ಸಿಕ್ಯೂಷನ್ ಪಾತ್ ಅನ್ನು ಬಳಸುತ್ತವೆ. HydraType ಇದಕ್ಕೆ ವಿರುದ್ಧವಾದ ವಿಧಾನವನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಇದು ಪ್ರತಿ ಟಾರ್ಗೆಟ್ DTO ಗಾಗಿ ವಿಶಿಷ್ಟವಾದ PHP ಕ್ಲಾಸ್ ಅನ್ನು ಜನರೇಟ್ ಮಾಡುತ್ತದೆ, ಆ ನಿರ್ದಿಷ್ಟ ಕ್ಲಾಸ್‌ಗೆ ಅಗತ್ಯವಿರುವ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾತ್ರ ಹೊರಸೂಸುತ್ತದೆ. ಸಂಕೀರ್ಣತೆಯು ಆಪ್ಟ್-ಇನ್ (opt-in) ಆಗುತ್ತದೆಯೇ ಹೊರತು, ಪ್ರತಿಯೊಂದು ಪ್ರಾಪರ್ಟಿಯ ಮೇಲೆ ವಿಧಿಸುವ ಸಾರ್ವತ್ರಿಕ ತೆರಿಗೆಯಾಗುವುದಿಲ್ಲ.

ವೇಗವು ಹೇಗೆ ಸಾಧ್ಯವಾಗುತ್ತದೆ

HydraType ಅನ್ನು ಸಾಮಾನ್ಯ ರಿಫ್ಲೆಕ್ಷನ್ ಆಧಾರಿತ ಪರಿಕರಗಳಿಂದ ಮತ್ತು ಇತರ ಜನರೇಟೆಡ್ ವಿಧಾನಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸುವ ನಾಲ್ಕು ನಿರ್ದಿಷ್ಟ ಆಯ್ಕೆಗಳು ಇಲ್ಲಿವೆ.

1. ಕೋಡ್ ಅನ್ನು ಒಮ್ಮೆ ಜನರೇಟ್ ಮಾಡಿ, ಎಂದೆಂದಿಗೂ ರನ್ ಮಾಡಿ

HydraType ನಿಮ್ಮ ಟಾರ್ಗೆಟ್ ಕ್ಲಾಸ್ ಅನ್ನು ಒಮ್ಮೆ ಮಾತ್ರ ಪರೀಕ್ಷಿಸುತ್ತದೆ, ನಂತರ ಅದರ ನಿಖರವಾದ ರೂಪಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಮೀಸಲಾದ PHP ಕ್ಲಾಸ್ ಅನ್ನು ಬರೆಯುತ್ತದೆ. ನಿಮ್ಮ DTO ನಲ್ಲಿ ಪಬ್ಲಿಕ್ ಸ್ಟ್ರಿಂಗ್ $name, ಇಂಟೆಜರ್ $status, ಮತ್ತು ಪ್ರೈವೇಟ್ DateTime $createdAt ಇದ್ದರೆ, ಜನರೇಟ್ ಆದ ರೈಟರ್ ಇವೆಲ್ಲವನ್ನೂ ಮೊದಲೇ ತಿಳಿಯುತ್ತದೆ. ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಯಾವುದೇ ಪುನರಾವರ್ತಿತ ರಿಫ್ಲೆಕ್ಷನ್, ಸ್ಟ್ರಿಂಗ್ ಪಾರ್ಸಿಂಗ್ ಅಥವಾ ಲೇಜಿ ಮೆಟಾಡೇಟಾ ಬಿಲ್ಡಿಂಗ್ ಇರುವುದಿಲ್ಲ. ಒಮ್ಮೆ OPCache ಜನರೇಟ್ ಮಾಡಿದ ಫೈಲ್ ಅನ್ನು ಕಾಂಪೈಲ್ ಮಾಡಿದ ನಂತರ, ಈ Hydrator ಕೈಯಾರೆ ಬರೆದ PHP ಯಂತೆಯೇ ಇರುತ್ತದೆ.

2. ಖಾಲಿ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕಿ

ಹೆಚ್ಚಿನ ಹೈಡ್ರೇಟರ್‌ಗಳು ತಮ್ಮ ಕೆಲಸವನ್ನು ರನ್‌ಟೈಮ್ ಪೈಪ್‌ಲೈನ್ ಸುತ್ತ ರಚಿಸುತ್ತವೆ. ಅವು ಮ್ಯುಟೇಟರ್‌ಗಳು, ವ್ಯಾಲಿಡೇಟರ್‌ಗಳು, ಟ್ರಾನ್ಸ್‌ಫಾರ್ಮರ್‌ಗಳಂತಹ ಕರಲಬಲ್ (callables) ಅರೇಯನ್ನು ಹೊಂದಿರುತ್ತವೆ ಮತ್ತು ಪ್ರತಿ ಮೌಲ್ಯದ ಮೇಲೆ ಇಟರೇಟ್ ಮಾಡುತ್ತವೆ. ಆ ಅರೇಗಳು ಖಾಲಿ ಇದ್ದಾಗಲೂ, foreach ಅಥವಾ array_reduce ಕಾರ್ಯಗತಗೊಳ್ಳುತ್ತದೆ. HydraType ಇದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಕೋಡ್ ಜನರೇಷನ್ ಸಮಯದಲ್ಲಿ ಅದು ಪ್ರಾಪರ್ಟಿಗೆ ನಿಜವಾಗಿಯೂ ಏನು ಬೇಕು ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಕಾರ್ಯಾಚರಣೆಗಳ ಪಟ್ಟಿ ಖಾಲಿ ಇದ್ದರೆ, ಅದು $object->name = $data['name']; ನಂತಹ ನೇರ ಅಸೈನ್‌ಮೆಂಟ್ ಅನ್ನು ನೀಡುತ್ತದೆ. ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಯಾವುದನ್ನೂ ಇಟರೇಟ್ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಜನರೇಟರ್ ಈಗಾಗಲೇ ಆ ಕೆಲಸವನ್ನು ಮಾಡಿದೆ.

3. ರಿಫ್ಲೆಕ್ಷನ್ ಬರವಣಿಗೆಯನ್ನು ತಪ್ಪಿಸಲು ಕ್ಲೋಸರ್ ಸ್ಕೋಪಿಂಗ್ ಬಳಸಿ

ಪ್ರೈವೇಟ್ ಪ್ರಾಪರ್ಟಿಗಳು ಬಾಹ್ಯ ಮ್ಯಾಪ್ಪರ್‌ಗಳಿಗೆ ದೊಡ್ಡ ತಲೆನೋವು. ಸಾಮಾನ್ಯ ಪರಿಹಾರ ReflectionProperty::setValue(), ಆದರೆ ಈ ವಿಧಾನವು ನೇರ ಪ್ರಾಪರ್ಟಿ ಅಕ್ಸೆಸ್‌ಗೆ ಹೋಲಿಸಿದರೆ ಹೆಚ್ಚಿನ ಹೊರೆಯನ್ನು ನೀಡುತ್ತದೆ. HydraType Closure::bind ಅನ್ನು ಬಳಸುವ ಮೂಲಕ ಇದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ಜನರೇಟ್ ಆದ ರೈಟರ್ ಟಾರ್ಗೆಟ್ ಕ್ಲಾಸ್‌ಗೆ ಸೀಮಿತವಾದ ಕ್ಲೋಸರ್ಸ್‌ಗಳನ್ನು (closures) ಹೊಂದಿರುತ್ತದೆ, ಇದು ರಿಫ್ಲೆಕ್ಷನ್ ಇಲ್ಲದೆ ಪ್ರೈವೇಟ್ ಮತ್ತು ಪ್ರೊಟೆಕ್ಟೆಡ್ ಪ್ರಾಪರ್ಟಿಗಳನ್ನು ನೇರವಾಗಿ ಸ್ಪರ್ಶಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಬೈಂಡಿಂಗ್ ರಚನೆಯ ಸಮಯದಲ್ಲಿ (construction) ಒಮ್ಮೆ ನಡೆಯುತ್ತದೆ; ಅದರ ನಂತರ, ಕ್ಲೋಸರ್ ನೈಸರ್ಗಿಕ ವೇಗದಲ್ಲಿ (near-native speed) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

4. ರೈಟರ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡಿ

ಕೆಲವು ಲೈಬ್ರರಿಗಳು ತಾವು ಹೈಡ್ರೇಟ್ ಮಾಡುವ ಪ್ರತಿಯೊಂದು ಆಬ್ಜೆಕ್ಟ್‌ಗಾಗಿ ಹೊಸ ಸ್ಟ್ರಾಟಜಿ ಅಥವಾ ರಿಫ್ಲೆಕ್ಷನ್ ಗ್ರಾಫ್ ಅನ್ನು ಇನ್‌ಸ್ಟಾಂಟಿಯೇಟ್ ಮಾಡುತ್ತವೆ. HydraType ತನ್ನ ರೈಟರ್ ಅನ್ನು ಒಮ್ಮೆ ಮಾತ್ರ ಸೃಷ್ಟಿಸುತ್ತದೆ, ನಂತರ ಸಾವಿರಾರು ಆಬ್ಜೆಕ್ಟ್‌ಗಳಾದ್ಯಂತ ಆ ಇನ್‌ಸ್ಟೆನ್ಸ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ. ಪ್ರತಿ ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ತಗಲುವ ವೆಚ್ಚವು ಪ್ರಾಪರ್ಟಿ ಮೌಲ್ಯಗಳನ್ನು ಸೆಟ್ ಮಾಡುವುದು ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಹಿಂತಿರುಗಿಸುವುದಕ್ಕೆ ಸೀಮಿತವಾಗಿರುತ್ತದೆ.

ಅಂಕಿಅಂಶಗಳು

PHP 8.2 ರಲ್ಲಿ, ವ್ಯತ್ಯಾಸವು ಎದ್ದು ಕಾಣುವಂತಿದೆ:

  • HydraType: 267.9 ns
  • Ocramius GeneratedHydrator: 307.9 ns
  • Symfony PropertyNormalizer: 8,499.0 ns
  • Valinor: 10,755.2 ns

Symfony PropertyNormalizer ಮತ್ತು Valinor ಶಕ್ತಿಯುತ ಸಾಧನಗಳಾಗಿವೆ, ಆದರೆ ಅವು ಸಾಮಾನ್ಯ ಉದ್ದೇಶದ (generalists) ಸಾಧನಗಳು. PropertyNormalizer ಎಂಬುದು ಫಾರ್ಮ್ಯಾಟ್ ಪತ್ತೆಹಚ್ಚುವಿಕೆ, ನಾರ್ಮಲೈಜರ್‌ಗಳು ಮತ್ತು ಆಳವಾದ ಆಬ್ಜೆಕ್ಟ್ ಗ್ರಾಫ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸೀರಿಯಲೈಜರ್ ಘಟಕದ ಭಾಗವಾಗಿದೆ. Valinor ಎಂಬುದು ಟೈಪ್ ಟ್ರೀಗಳು ಮತ್ತು ಕೋಯರ್ಷನ್ ವಿಷಯದಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾಗಿದೆ. ಆ ಶಕ್ತಿಯು ಒಂದು ಬೆಲೆಯನ್ನು ತೆರಬೇಕಾಗುತ್ತದೆ. ಈ ಪರೀಕ್ಷೆಯಲ್ಲಿ, ಅವು HydraType ಗಿಂತ ಸುಮಾರು ಮೂವತ್ತು ರಿಂದ ನಲವತ್ತು ಪಟ್ಟು ನಿಧಾನವಾಗಿದ್ದವು. ಈಗಾಗಲೇ ಕೋಡ್ ಜನರೇಷನ್ ಬಳಸುವ Ocramius GeneratedHydrator ಕೂಡ ಪೈಪ್‌ಲೈನ್‌ಗಳು ಮತ್ತು ಪ್ರಾಪರ್ಟಿ ಅಕ್ಸೆಸ್‌ನ ಸುತ್ತಲಿನ ವಾಸ್ತುಶಿಲ್ಪದ ವ್ಯತ್ಯಾಸಗಳಿಂದಾಗಿ ಸ್ವಲ್ಪ ಹಿಂದೆ ಉಳಿದಿದೆ.

ಸಂದರ್ಭವು ಮುಖ್ಯವಾಗುತ್ತದೆ. ಒಂದು ಸಿಂಗಲ್ ಡೇಟಾಬೇಸ್ ಕ್ವೇರಿ ಅಥವಾ ಒಂದು HTTP ರೌಂಡ್ಟ್ರಿಪ್ ಈ ಎಲ್ಲಾ ಸಂಖ್ಯೆಗಳಿಗಿಂತ ದೊಡ್ಡದಾಗಿರುತ್ತದೆ. ನೀವು ಒಂದು ಕ್ವೇರಿಯ ನಂತರ ಮೂರು ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡುತ್ತಿದ್ದರೆ, ನ್ಯಾನೋಸೆಕೆಂಡ್‌ಗಳ ಹಿಂದೆ ಬೀಳುವುದು ಶಕ್ತಿಯ ವ್ಯರ್ಥ. ನೀವು ಸ್ಕೇಲ್ ಮಾಡಿದಾಗ ಈ ಅಂತರವು ಅರ್ಥಪೂರ್ಣವಾಗುತ್ತದೆ. ಐವತ್ತು ಸಾವಿರ ರೆಕಾರ್ಡ್‌ಗಳನ್ನು ಹೈಡ್ರೇಟ್ ಮಾಡುವ ಬ್ಯಾಚ್ ಪ್ರಕ್ರಿಯೆ ಅಥವಾ ಕ್ಯಾಶ್ ಅರೇಗಳಿಂದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಮರುನಿರ್ಮಿಸುವ ಕ್ಯೂ ಕನ್ಸ್ಯೂಮರ್, 267 ನ್ಯಾನೋಸೆಕೆಂಡ್‌ಗಳು ಮತ್ತು ಹತ್ತು ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಅನುಭವಿಸುತ್ತದೆ. ಫೀಲ್ಡ್‌ಗಳು ಮತ್ತು ರೋಗಳ ಮೂಲಕ ಇದನ್ನು ಗುಣಿಸಿದಾಗ, ಯಾವುದೇ ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ ಅನ್ನು ಬದಲಾಯಿಸದೆ ವೇಗವಾದ ಮ್ಯಾಪ್ಪರ್ ಕೆಲಸದ ಸಮಯವನ್ನು ಸೆಕೆಂಡುಗಳಷ್ಟು ಕಡಿಮೆ ಮಾಡಬಹುದು.

ನಿಜವಾದ ಸಾರಾಂಶ

ಇಲ್ಲಿನ ಪಾಠವೆಂದರೆ ಪ್ರತಿಯೊಂದು ಪ್ರಾಜೆಕ್ಟ್‌ಗೂ ಕಸ್ಟಮ್ ಹೈಡ್ರೇಟರ್ ಅಗತ್ಯವಿದೆ ಎಂದಲ್ಲ. ವಾಸ್ತುಶಿಲ್ಪದ ಆಯ್ಕೆಗಳ ಪರಿಣಾಮವು ಕ್ರಮೇಣ ಹೆಚ್ಚಾಗುತ್ತದೆ ಎಂಬುದು ಇದರ ಸಾರ. ನೀವು ಕೇಳಿದದ್ದನ್ನು ಮಾತ್ರ ಒಳಗೊಂಡಿರುವ ಕೋಡ್ ಅನ್ನು ಜನರೇಟ್ ಮಾಡುವ ಮೂಲಕ, HydraType ಸಂಕೀರ್ಣವಾದವುಗಳಿಗೆ ಪರ್ಯಾಯ ಮಾರ್ಗವನ್ನು (escape hatch) ನೀಡುತ್ತಲೇ ಸಾಮಾನ್ಯ ಪ್ರಾಪರ್ಟಿಗಳನ್ನು ವೇಗವಾಗಿರಿಸುತ್ತದೆ. ಟೈಪ್ ಕನ್ವರ್ಷನ್ ಮತ್ತು ನೆಸ್ಟೆಡ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ನಿಮಗೆ ಅಗತ್ಯವಿದ್ದಾಗ ಲಭ್ಯವಿರುತ್ತವೆ, ಆದರೆ ಅವು ಆಬ್ಜೆಕ್ಟ್‌ನಲ್ಲಿರುವ ಪ್ರತಿಯೊಂದು ಸ್ಕೇಲರ್ ಸ್ಟ್ರಿಂಗ್‌ನ ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಮೇಲೆ ಹೊರೆಯಾಗುವುದಿಲ್ಲ.

ನೀವು ಪರಿಕರಗಳನ್ನು ಬದಲಾಯಿಸುವ ಮೊದಲು, ಪ್ರೊಫೈಲ್ ಮಾಡಿ. ನಿಮ್ಮ ನೈಜ-ಪ್ರಪಂಚದ ಟ್ರೇಸ್‌ಗಳಲ್ಲಿ ಹೈಡ್ರೇಶನ್ ಕಂಡುಬರದಿದ್ದರೆ, ಸರಿಪಡಿಸಲು ಏನೂ ಇಲ್ಲ. ಆದರೆ ನೀವು ಜನರಿಕ್ ಮ್ಯಾಪ್ಪರ್‌ಗಳ ಮೂಲಕ ದೊಡ್ಡ ಡೇಟಾ ಸೆಟ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತಾ CPU ಬಳಕೆಯನ್ನು ಗಮನಿಸುತ್ತಿದ್ದರೆ, ಸಾಮಾನ್ಯ PHP ಅಸೈನ್‌ಮೆಂಟ್ ಇನ್ನೂ ಲಭ್ಯವಿದೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ಕೆಲವೊಮ್ಮೆ ಅತ್ಯಂತ ವೇಗವಾದ ಕೋಡ್ ಎಂದರೆ ನೀವು ಸ್ವತಃ ಬರೆದಿದ್ದ, ಒಮ್ಮೆ ಜನರೇಟ್ ಮಾಡಿ ನಂತರ ಮರೆತುಹೋದ ಕೋಡ್ ಆಗಿರುತ್ತದೆ.