JavaScript ಟೂಲಿಂಗ್ ಕ್ಷೇತ್ರದಲ್ಲಿನ ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯ (performance) ಹಕ್ಕುಗಳು ಹಾಲಿನಂತಹ ಅಲ್ಪ ಜೀವಿತಾವಧಿಯನ್ನು ಹೊಂದಿವೆ. ಯಾರೋ ಒಬ್ಬರು ಒಂದು ಮಂಗಳವಾರ ಬೆಳಿಗ್ಗೆ ಕೆಲವು ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿ, ಟರ್ಮಿನಲ್ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಸೆರೆಹಿಡಿದು, ಒಂದು ನಾಟಕೀಯ ಬಾರ್ ಚಾರ್ಟ್ ಅನ್ನು ಪ್ರಕಟಿಸುತ್ತಾರೆ. ಮುಂದಿನ ಸ್ಪ್ರಿಂಟ್‌ಗೆ, ಒಂದು ಟೂಲ್ ಹೊಸ ಪ್ಯಾಚ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದು ಇಡೀ ಮಾಹಿತಿಯನ್ನು ಅಸಿಂಧುಗೊಳಿಸುತ್ತದೆ. ಆದರೂ ಆ ಪೋಸ್ಟ್ ಸರ್ಚ್ ಇಂಜಿನ್‌ಗಳಲ್ಲಿ ಇರುತ್ತದೆ. ಚಾರ್ಟ್ ಹಂಚಿಕೆಯಾಗುತ್ತಲೇ ಇರುತ್ತದೆ. ಆದರೆ, ಆ ಅಂಕಿಅಂಶಗಳು ಈಗಾಗಲೇ ನಿಮಗೆ ಸುಳ್ಳು ಹೇಳುತ್ತಿರುತ್ತವೆ.

ಇದು ಬಹುತೇಕ ಎಲ್ಲಾ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳನ್ನು ಬಾಧಿಸುವ ದೋಷವಾಗಿದೆ. ನಮಗೆ ಬೇಕಾಗಿರುವುದು ಲೈವ್ ಫೀಡ್ (live feed) ಆಗಿದ್ದಾಗ, ಇವು ಕೇವಲ ಒಂದು ಕ್ಷಣದ ಫೋಟೋಗ್ರಫಿಯಂತೆ ಇರುತ್ತವೆ.

depjs/canary ಎಂಬ ಯೋಜನೆಯು ಈ ಸಮಸ್ಯೆಯನ್ನು ಕಂಟೆಂಟ್ ಕ್ಯಾಲೆಂಡರ್ ಕಾರ್ಯವಾಗಿ ನೋಡದೆ, ಯಂತ್ರದ ಜವಾಬ್ದಾರಿಯಾಗಿ ಪರಿಗಣಿಸುತ್ತದೆ. ಇದು npm, pnpm, Yarn, ಮತ್ತು dep ಅನ್ನು ಗಮನಿಸುವ ಒಂದು ಜೀವಂತ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಆಗಿದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಹೊಸ ವರ್ಷನ್ ಬಿಡುಗಡೆ ಮಾಡಿದ ತಕ್ಷಣ ತನ್ನ ಸಂಪೂರ್ಣ ಸರಣಿಯನ್ನು ಮರು-ಚಾಲನೆ ಮಾಡುತ್ತದೆ. ಇದರ ಫಲಿತಾಂಶಗಳು ಸಾರ್ವಜನಿಕವಾಗಿವೆ, ನಿರಂತರವಾಗಿವೆ ಮತ್ತು ತಪ್ಪಿಸಿಕೊಳ್ಳಲಾಗದವುಗಳಾಗಿವೆ. ಏನಾದರೂ ತಪ್ಪಾದಾಗ, ಅದು ಸರಿಹೋಗುವವರೆಗೆ ರೆಪೊಸಿಟರಿ (repository) ಕೆಂಪು ಬಣ್ಣದಲ್ಲೇ ಇರುತ್ತದೆ. ಇಲ್ಲಿ ಯಾವುದೇ ಹಳೆಯ ಮಾಹಿತಿಯನ್ನು ಆರಿಸಿಕೊಳ್ಳಲು (cherry-picking) ಅಥವಾ ಹಳೆಯ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ ಹಿಂದೆ ಅಡಗಿಕೊಳ್ಳಲು ಅವಕಾಶವಿಲ್ಲ, ಮತ್ತು ಕಳೆದ ತಿಂಗಳ ವಿಜೇತನೇ ಇಂದಿಗೂ ಚಾಂಪಿಯನ್ ಎಂಬ ಕಲ್ಪನೆಯೂ ಇಲ್ಲ.

ವೇಗದ ಹಕ್ಕುಗಳಿಗೆ ಏಕೆ ಅವಧಿ ಮುಕ್ತಾಯದ ದಿನಾಂಕ (Expiration Date) ಅಗತ್ಯವಿದೆ

JavaScript ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್‌ಗಳು ಸ್ಥಗಿತವಾಗಿರುವುದಿಲ್ಲ. ಮೈನರ್ ವರ್ಷನ್‌ಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು ಮರು-ಬರೆಯಲಾದ ರೆಸಲ್ಯೂಶನ್ ಅಲ್ಗಾರಿದಮ್‌ಗಳು (resolution algorithms), ಬದಲಾದ ಹೋಸ್ಟಿಂಗ್ ತಂತ್ರಗಳು (hoisting strategies), ಅಥವಾ ಗ್ಲೋಬಲ್ ಕ್ಯಾಶ್ (global cache) ಕೀ ಮಾಡುವ ವಿಧಾನದ ಬದಲಾವಣೆಗಳನ್ನು ಒಳಗೊಂಡಿರಬಹುದು. npm 10.2.1 ಮತ್ತು pnpm 8.11.0 ಅನ್ನು ಸೆರೆಹಿಡಿಯುವ ಬೆಂಚ್‌ಮಾರ್ಕ್, ಎರಡು ಬಿಡುಗಡೆಗಳ ನಂತರ ಅದೇ ಟೂಲ್‌ಗಳು ಹೇಗೆ ವರ್ತಿಸುತ್ತವೆ ಎಂಬುದರ ಬಗ್ಗೆ ನಿಮಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಆದರೂ, ಇಂತಹ ಸ್ಥಿರವಾದ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ "ಟೂಲ್ X ಮೂರು ಪಟ್ಟು ವೇಗವಾಗಿದೆ" ಎಂಬಂತಹ ಖಚಿತ ಹೇಳಿಕೆಗಳಿಂದ ವೆಬ್ ತುಂಬಿದೆ.

ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದೇನೆ, ಅನೇಕ ಪರೀಕ್ಷೆಗಳು ನೈಜ ಡೆವಲಪರ್‌ಗಳ ತೊಂದರೆಯನ್ನು ನಿರ್ಧರಿಸುವ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ. ಒಂದು ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಉತ್ತಮವಾಗಿ ಸಿದ್ಧಗೊಂಡಿರುವ (warm) ಪರಿಸರದಲ್ಲಿ ಇನ್‌ಸ್ಟಾಲೇಶನ್ ಅನ್ನು ವೇಗವಾಗಿ ಮಾಡಬಹುದು, ಆದರೆ ಖಾಲಿ ಡಿಸ್ಕ್ ಹೊಂದಿರುವ CI ರನ್ನರ್‌ನಲ್ಲಿ ಅದು ತುಂಬಾ ನಿಧಾನವಾಗಬಹುದು. ಎರಡೂ ಅತಿರೇಕದ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ಪರೀಕ್ಷಿಸದೆ, ಬೆಂಚ್‌ಮಾರ್ಕ್ ಕೇವಲ ಒಂದು ಪ್ರೆಸ್ ರಿಲೀಸ್ ಆಗುತ್ತದೆಯೇ ಹೊರತು ಉಪಯುಕ್ತ ಎಂಜಿನಿಯರಿಂಗ್ ಡೇಟಾ ಆಗುವುದಿಲ್ಲ.

Canary ಹೇಗೆ ಹೋಲಿಕೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತದೆ

ಪ್ರತಿ ಎರಡು ಗಂಟೆ마다, ಒಂದು ಕೆಲಸವು npm ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ (polls). npm, pnpm, Yarn, ಅಥವಾ dep ನ ಹೊಸ ವರ್ಷನ್ ಕಾಣಿಸಿಕೊಂಡರೆ, canary ಜಾಗೃತಗೊಳ್ಳುತ್ತದೆ. ಚೇಂಜ್‌ಲಾಗ್ (changelog) ಅನ್ನು ಗಮನಿಸಲು ಇದು ಮನುಷ್ಯರಿಗಾಗಿ ಕಾಯುವುದಿಲ್ಲ. ಇದು ತಕ್ಷಣವೇ ನಾಲ್ಕೂ ಮ್ಯಾನೇಜರ್‌ಗಳನ್ನು ಐದು ಜನಪ್ರಿಯ, ನೈಜ-ಪ್ರಪಂಚದ ಪ್ಯಾಕೇಜ್‌ಗಳ ವಿರುದ್ಧ ಪರೀಕ್ಷಿಸುವ ಪೂರ್ಣ ಟೆಸ್ಟ್ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ಈ ಆಯ್ಕೆಯಲ್ಲಿ React, Next.js, ಮತ್ತು Vite ನಂತಹ ದೊಡ್ಡ ಪ್ಯಾಕೇಜ್‌ಗಳು ಸೇರಿವೆ, ಇವುಗಳನ್ನು ನೈಜ ಡೆವಲಪರ್‌ಗಳು ಪ್ರತಿದಿನ ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡುತ್ತಾರೆ. ಇವು ಯಾವುದೋ ಒಂದು ನಿರ್ದಿಷ್ಟ ಟೂಲ್ ಅನ್ನು ಹೊಗಳುவதற்காக ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಕೃತಕ ಮೈಕ್ರೋ-ಪ್ರಾಜೆಕ್ಟ್‌ಗಳಲ್ಲ.

ಈ ಬಿಡುಗಡೆ-ಪ್ರೇರಿತ (release-triggered) ವಿಧಾನವು ಮುಖ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಅಳತೆಯನ್ನು ನೇರವಾಗಿ ಬದಲಾವಣೆಯೊಂದಿಗೆ ಜೋಡಿಸುತ್ತದೆ. ಬೆಂಚ್‌ಮಾರ್ಕ್ ಕೇವಲ ರಾತ್ರಿ ವೇಳೆಯ ವೇಳಾಪಟ್ಟಿಯಲ್ಲಿ ರನ್ ಆಗಿದ್ದರೆ, ಅದು ಮಧ್ಯಾಹ್ನದ ಹಾಟ್‌ಫಿಕ್ಸ್ ಅನ್ನು ತಪ್ಪಿಸಬಹುದು ಅಥವಾ ತೊಂದರೆಯನ್ನು (regression) ಗಂಟೆಗಟ್ಟಲೆ ಗುರುತಿಸದೆ ಬಿಡಬಹುದು. ಹೊಸ ವರ್ಷನ್‌ಗಳ ಮೇಲೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ರನ್ ಮಾಡುವ ಮೂಲಕ, canary ಪ್ರತಿ ಬಾರಿಯೂ ನೇರವಾದ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳುತ್ತದೆ: ಈ ಬಿಡುಗಡೆಯು ವಿಷಯಗಳನ್ನು ಉತ್ತಮಗೊಳಿಸಿದೆಯೇ ಅಥವಾ ಇನ್ನಷ್ಟು ಕೆಡಿಸಿದೆಯೇ?

ವಿವಿಧ ಕಾರ್ಯಕ್ಷಮತೆಗಳನ್ನು ಪರೀಕ್ಷಿಸುವ ನಾಲ್ಕು ಸನ್ನಿವೇಶಗಳು

ಟೆಸ್ಟ್ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನ್ನು ನೀವು ಗುರುತಿಸಬಹುದಾದ ವರ್ಕ್‌ಫ್ಲೋಗಳಿಗೆ (workflows) ನೇರವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವ ನಾಲ್ಕು ವಿಭಿನ್ನ ಸೆಟಪ್‌ಗಳ ಸುತ್ತ ನಿರ್ಮಿಸಲಾಗಿದೆ.

  • Cold cache, no lockfile. ಇದು ಹೊಸ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಮಾಡುವ ಫ್ರೆಶ್ ಕ್ಲೋನ್ (fresh clone), ಅಥವಾ node_modules ಅನ್ನು ಡಿಲೀಟ್ ಮಾಡಿದ ನಂತರದ ಮೊದಲ ಇನ್‌ಸ್ಟಾಲೇಶನ್ ಆಗಿದೆ. ಯಾವುದೂ ಕ್ಯಾಶ್ ಆಗಿರುವುದಿಲ್ಲ. ಯಾವುದೂ ಪಿನ್ ಆಗಿರುವುದಿಲ್ಲ. ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಎಲ್ಲವನ್ನೂ ಮೊದಲಿನಿಂದಲೇ ರೆಸಲ್ಯೂಲ್ ಮಾಡಿ, ಫೆಚ್ ಮಾಡಿ ಮತ್ತು ಬರೆಯಬೇಕಾಗುತ್ತದೆ.
  • Warm cache, with lockfile. ಇದು ಸತತ ಏಕೀಕರಣದ (continuous integration) ಸಮಯದಲ್ಲಿ ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ನಡೆದಾಗ ಇರುವ ಸುಗಮ ಹಾದಿಯಾಗಿದೆ. ಲೋಕ್‌ಫೈಲ್ (lockfile) ಸ್ಥಳೀಯವಾಗಿ ಲಭ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಕ್ಯಾಶ್ ಇನ್ನೂ ಹಿಂದಿನ ರನ್‌ನ ಟಾರ್‌ಬಾಲ್‌ಗಳನ್ನು (tarballs) ಹೊಂದಿರುತ್ತದೆ. ಹೆಚ್ಚಿನ ನಿರ್ಧಾರಗಳು ಈಗಾಗಲೇ ಆಗಿರುವುದರಿಂದ ಟೂಲ್ ವೇಗವಾಗಿ ಕೆಲಸ ಮಾಡಬೇಕು.
  • Cold cache, with lockfile. ಇಲ್ಲಿ ಲೋಕ್‌ಫೈಲ್ ಇದೆ, ಆದರೆ ಕ್ಯಾಶ್ ಅನ್ನು ಅಳಿಸಲಾಗಿದೆ. ಮ್ಯಾನೇಜರ್ ಡಿಪೆಂಡೆನ್ಸಿ ರೆಸಲ್ಯೂಶನ್ ಅನ್ನು ಬಿಡಬಹುದು, ಆದರೆ ಆದರೂ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಪ್ರತಿ ಬೈಟ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಇದು ರೆಸಲ್ಯೂಶನ್ ವೇಗದಿಂದ ನೆಟ್‌ವರ್ಕ್ ವೇಗವನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ.
  • Warm cache, no lockfile. ಕ್ಯಾಶ್ ಸಿದ್ಧವಾಗಿದೆ (hot), ಆದರೆ ಲೋಕ್‌ಫೈಲ್ ಇಲ್ಲ. ಫೈಲ್‌ಗಳನ್ನು ಹೊರತೆಗೆಯಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲೇ ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ಡಿಪೆಂಡೆನ್ಸಿ ಟ್ರೀ ಅನ್ನು ಮರು-ರೆಸಲ್ಯೂಲ್ ಮಾಡಬೇಕು. ಇದು ಆದರ್ಶ ನೆಟ್‌ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಸಾಲ್ವರ್ (solver) ಮತ್ತು ಮೆಟಾಡೇಟಾ ಪಾರ್ಸರ್‌ನ ದಕ್ಷತೆಯನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ.

ಪ್ರತಿ ಸನ್ನಿವೇಶವನ್ನು ಐದು ಬಾರಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಮತ್ತು canary ಅದರ ಮೀಡಿಯನ್ (median) ಫಲಿತಾಂಶವನ್ನು ಇರಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಈ ಒಂದು ಆಯ್ಕೆಯು ಹೆಚ್ಚಿನ ಗೊಂದಲಗಳನ್ನು (noise) ತಪ್ಪಿಸುತ್ತದೆ. ಒಂದು ತಾತ್ಕಾಲಿಕ ನೆಟ್‌ವರ್ಕ್ ಏರುಪೇರು ಅಥವಾ ರಿಜಿಸ್ಟ್ರಿ ವಿಳಂಬವು (latency) ಇಡೀ ವರದಿಯನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಹೊರಗುಳಿದ (outlier) ಫಲಿತಾಂಶವನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತದೆ; ಸಾಮಾನ್ಯ ಅನುಭವವನ್ನು ದಾಖಲಿಸಲಾಗುತ್ತದೆ.

ಸ್ಮೋಕ್ ಟೆಸ್ಟ್‌ಗಳು (Smoke Tests) ಖಾಲಿ ಟೈಮರ್‌ಗಳಿಗಿಂತ ಉತ್ತಮ

Raw speed is easy to fake if you do not verify the outcome. A package manager could skip postinstall steps, corrupt a few symlinks, or install the wrong versions and still post an impressive timestamp. The canary refuses to stop at the timer. After the installation finishes, it actually exercises the installed code.

For example, it boots up an Express application and confirms that the server starts listening on the expected port. If the code does not run, the benchmark fails outright. The smoke test transforms the suite from a race into an audit. It answers the question that speed alone cannot: does the installation actually work?

Radical Honesty as a Feature

The author of the canary wrote three rules into the process that most benchmark authors treat as optional.

Same playing field. Flags are used to normalize behavior across tools. If one package manager hides a performance flaw behind a default setting, the benchmark exposes it rather than letting the tool look good by accident.

Genuine cold starts. Before every single repetition, not just the first one, the npm cache and the pnpm store get wiped. That word "every" is doing heavy labor. Many benchmarks clear the cache once, then run five installs in a row. The second through fifth runs are not truly cold, and the numbers inflate accordingly. The canary starts from zero each time.

Public failure states. When a new release breaks something, the repository remains in a red failure state. It sits there on the front page, ugly and unresolved, until a fix ships. There is no silent suppression to keep the dashboard looking green. This policy forces visibility. A user evaluating tools can see not just which one is fastest, but which one stayed reliable over time.

Inspectability Is Non-Negotiable

A benchmark that you cannot reproduce is a campaign slogan. The canary addresses this with a single bash script that lets anyone run any slice of the suite locally. You do not need to trust a cloud provider’s networking or a maintainer’s hand-tweaked environment. If you suspect the numbers are off, you can generate your own.

That transparency also makes the project useful for maintainers. When a regression hits, a downstream developer can pull the script, bisect the tool’s releases, and hand the upstream team a