Most performance claims in the JavaScript tooling space have the shelf life of milk. Someone installs a few packages on a quiet Tuesday morning, captures the terminal output, and publishes a dramatic bar chart. By the next sprint, one of the tools has shipped a patch that invalidates the whole thing. The post remains indexed by search engines. The chart keeps getting shared. The numbers, however, are already lying to you.

This is the rot that infects nearly all package manager benchmarks. They are event photography when what we need is a live feed.

A project called depjs/canary treats this problem as a machine responsibility rather than a content calendar task. It is a living benchmark that watches npm, pnpm, Yarn, and dep, then re-runs its entire suite the moment any of them publishes a new version. The results are public, continuous, and unavoidable. When something breaks, the repository stays red until it heals. There is no cherry-picking, no hiding behind an old blog post, and no assumption that last month’s winner still holds the crown.

വേഗതയെക്കുറിച്ചുള്ള അവകാശവാദങ്ങൾക്ക് എന്തുകൊണ്ട് ഒരു കാലാവധി ആവശ്യമാണ്

JavaScript പാക്കേജ് മാനേജറുകൾ നിശ്ചലമല്ല. മൈനർ വേർഷനുകൾക്കിടയിലുള്ള വ്യത്യാസത്തിൽ റസല്യൂഷൻ അൽഗോരിതങ്ങളുടെ മാറ്റം, ഹോസ്റ്റിംഗ് സ്ട്രാറ്റജികളിലെ മാറ്റം, അല്ലെങ്കിൽ ഗ്ലോബൽ കാഷെ കീയിംഗിലെ മാറ്റങ്ങൾ എന്നിവ ഉൾപ്പെട്ടേക്കാം. npm 10.2.1-ഉം pnpm 8.11.0-ഉം ഉപയോഗിച്ച് നടത്തുന്ന ഒരു ബെഞ്ച്മാർക്ക്, രണ്ട് റിലീസുകൾക്ക് ശേഷം ആ ടൂളുകൾ എങ്ങനെ പ്രവർത്തിക്കും എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. എന്നിട്ടും, ഇത്തരം നിശ്ചലമായ വിവരങ്ങൾ അടിസ്ഥാനമാക്കി "ടൂൾ X മൂന്ന് മടങ്ങ് വേഗതയുള്ളതാണ്" എന്നതുപോലുള്ള ഉറപ്പായ പ്രസ്താവനകൾ വെബിൽ നിറഞ്ഞുനിൽക്കുന്നു.

ഇതിലും മോശമായ കാര്യം, ഡെവലപ്പർമാർ നേരിടുന്ന യഥാർത്ഥ വെല്ലുവിളികളെ പല ടെസ്റ്റുകളും അവഗണിക്കുന്നു എന്നതാണ്. ഒരു പാക്കേജ് മാനേജർ മികച്ച സാഹചര്യങ്ങളിൽ വളരെ വേഗത്തിൽ ഇൻസ്റ്റാൾ ചെയ്തേക്കാം, എന്നാൽ ശൂന്യമായ ഡിസ്കുള്ള ഒരു CI റണ്ണറിൽ അത് വളരെ സാവധാനത്തിലാകാം. രണ്ട് സാഹചര്യങ്ങളും പരിശോധിക്കാതെ, ഒരു ബെഞ്ച്മാർക്ക് ഉപയോഗപ്രദമായ എഞ്ചിനീയറിംഗ് ഡാറ്റയ്ക്ക് പകരം വെറുമൊരു പ്രസ് റിലീസ് മാത്രമായി മാറുന്നു.

കാനറി (Canary) എങ്ങനെയാണ് താരതമ്യം ഓട്ടോമേറ്റ് ചെയ്യുന്നത്

ഓരോ രണ്ട് മണിക്കൂർ കൂടുമ്പോഴും, ഒരു ജോബ് npm രജിസ്ട്രി പരിശോധിക്കുന്നു. npm, pnpm, Yarn, അല്ലെങ്കിൽ dep എന്നിവയുടെ പുതിയ വേർഷൻ കണ്ടാൽ കാനറി ഉണരുന്നു. ഒരു മനുഷ്യൻ ചേഞ്ച്‌ലോഗ് ശ്രദ്ധിക്കാൻ കാത്തുനിൽക്കുന്നതിന് പകരം, ഇത് ഉടൻ തന്നെ നാല് മാനേജർമാരെയും അഞ്ച് പ്രശസ്തമായ പാക്കേജുകളുമായി താരതമ്യം ചെയ്യുന്ന ഒരു ഫുൾ ടെസ്റ്റ് മാട്രിക്സ് പ്രവർത്തിപ്പിക്കുന്നു. ഇതിനായി React, Next.js, Vite തുടങ്ങിയ ഡെവലപ്പർമാർ ദിവസവും ഉപയോഗിക്കുന്ന വലിയ പാക്കേജുകളാണ് തിരഞ്ഞെടുക്കുന്നത്. ഒരു പ്രത്യേക ടൂളിനെ പ്രശംസിക്കാൻ വേണ്ടി ഉണ്ടാക്കിയ കൃത്രിമ പ്രോജക്റ്റുകളല്ല ഇവ.

ഈ റിലീസ്-ട്രിഗർഡ് രീതി പ്രധാനമാകുന്നത് അളവുകളെ മാറ്റങ്ങളുമായി നേരിട്ട് ബന്ധിപ്പിക്കുന്നത് കൊണ്ടാണ്. ബെഞ്ച്മാർക്ക് ഒരു നിശ്ചിത സമയക്രമത്തിൽ മാത്രം നടന്നതെങ്കിൽ, പകൽ സമയത്തുണ്ടാകുന്ന ഒരു ചെറിയ മാറ്റമോ (hotfix) അല്ലെങ്കിൽ ഒരു തകരാറോ ശ്രദ്ധിക്കപ്പെടാതെ പോയേക്കാം. പുതിയ വേർഷനുകൾ വരുമ്പോൾ മാത്രം പ്രവർത്തിക്കുന്നതിലൂടെ, "ഈ റിലീസ് കാര്യങ്ങൾ മെച്ചപ്പെടുത്തിയോ അതോ മോശമാക്കിയോ?" എന്ന ചോദ്യത്തിന് കാനറി നേരിട്ട് ഉത്തരം നൽകുന്നു.

വ്യത്യസ്ത സാഹചര്യങ്ങളെ പരിശോധിക്കുന്ന നാല് രീതികൾ

നിങ്ങൾ ഉപയോഗിക്കുന്ന വർക്ക്ഫ്ലോകളുമായി നേരിട്ട് ബന്ധമുള്ള നാല് വ്യത്യസ്ത സാഹചര്യങ്ങളെ അടിസ്ഥാനമാക്കിയാണ് ടെസ്റ്റ് മാട്രിക്സ് നിർമ്മിച്ചിരിക്കുന്നത്.

  • Cold cache, no lockfile. പുതിയൊരു ലാപ്ടോപ്പിലെ ഫ്രഷ് ക്ലോൺ അല്ലെങ്കിൽ node_modules ഡിലീറ്റ് ചെയ്ത ശേഷമുള്ള ആദ്യ ഇൻസ്റ്റാളേഷൻ പോലെയാണിത്. ഇവിടെ ഒന്നും കാഷെ ചെയ്തിട്ടില്ല, ഒന്നും ലോക്ക് ചെയ്തിട്ടില്ല. പാക്കേജ് മാനേജർക്ക് എല്ലാം ആദ്യം മുതൽ തന്നെ റസല്യൂട്ട് ചെയ്യാനും ഫെച്ച് ചെയ്യാനും എഴുതാനും necessity ഉണ്ട്.
  • Warm cache, with lockfile. കാര്യങ്ങൾ കൃത്യമായി നടക്കുമ്പോൾ സിഐ (CI) പ്രക്രിയയിൽ കാണുന്ന സാഹചര്യമാണിത്. ലോക്ക് ഫയൽ പ്രാദേശികമായി ലഭ്യമാണ്, കൂടാതെ മുൻപത്തെ റണ്ണിൽ നിന്നുള്ള ടാർബോളുകൾ കാഷെയിലുണ്ട്. മിക്ക തീരുമാനങ്ങളും നേരത്തെ എടുത്തിട്ടുള്ളതിനാൽ ടൂൾ വേഗത്തിൽ പ്രവർത്തിക്കണം.
  • Cold cache, with lockfile. ഇവിടെ ലോക്ക് ഫയൽ ഉണ്ട്, പക്ഷേ കാഷെ മായ്ച്ചു കളഞ്ഞിരിക്കുന്നു. മാനേജർക്ക് डिपൻഡൻസി റസല്യൂഷൻ ഒഴിവാക്കാം, എങ്കിലും നെറ്റ്‌വർക്ക് വഴി ഓരോ ബൈറ്റും ഡൗൺലോഡ് ചെയ്യേണ്ടി വരും. ഇത് നെറ്റ്‌വർക്ക് വേഗതയെ റസല്യൂഷൻ വേഗതയിൽ നിന്ന് വേർതിരിച്ചു കാണിക്കുന്നു.
  • Warm cache, no lockfile. കാഷെ ലഭ്യമാണ്, പക്ഷേ ലോക്ക് ഫയൽ ഇല്ല. ഫയലുകൾ എക്സ്ട്രാക്ട് ചെയ്യുന്നതിന് മുമ്പ് പാക്കേജ് മാനേജർക്ക് डिपൻഡൻസി ട്രീ വീണ്ടും റസല്യൂട്ട് ചെയ്യേണ്ടതുണ്ട്. ഇത് മികച്ച നെറ്റ്‌വർക്ക് സാഹചര്യങ്ങളിൽ സോൾവറിന്റെയും മെറ്റാഡാറ്റ പാഴ്സറുടെയും കാര്യക്ഷമത പരിശോധിക്കുന്നു.

ഓരോ സാഹചര്യവും അഞ്ച് തവണ വീതം പ്രവർത്തിപ്പിക്കുന്നു, കാനറി അതിന്റെ മീഡിയൻ (median) ഫലം മാത്രം സൂക്ഷിക്കുന്നു. ഈ രീതി അനാവശ്യമായ വ്യതിയാനങ്ങളെ (noise) ഒഴിവാക്കുന്നു. ഒരു ചെറിയ നെറ്റ്‌വർക്ക് തടസ്സമോ രജിസ്ട്രിയിലെ താമസമോ ഫലത്തെ ബാധിക്കില്ല. അസാധാരണമായ മാറ്റങ്ങൾ അവഗണിക്കപ്പെടുകയും സാധാരണമായ അനുഭവം രേഖപ്പെടുത്തുകയും ചെയ്യുന്നു.

സ്മോക്ക് ടെസ്റ്റുകൾ (Smoke Tests) ശൂന്യമായ ടൈമറുകളേക്കാൾ മികച്ചതാണ്

ഫലം പരിശോധിച്ചില്ലെങ്കിൽ വെറും വേഗത കാണിച്ചാൽ മാത്രം മതിയാകില്ല. ഒരു പാക്കേജ് മാനേജർക്ക് പോസ്റ്റ് ഇൻസ്റ്റാൾ (postinstall) ഘട്ടങ്ങൾ ഒഴിവാക്കാനോ, ചില സിംലിങ്കുകൾ (symlinks) കേടുവരുത്താനോ, തെറ്റായ പതിപ്പുകൾ ഇൻസ്റ്റാൾ ചെയ്യാനോ സാധിച്ചേക്കാം, എന്നിട്ടും മികച്ച ഒരു ടൈംസ്റ്റാമ്പ് നൽകാൻ അവന് കഴിയും. എന്നാൽ കാനറി (the canary) വെറും ടൈമറിൽ മാത്രം ഒതുങ്ങുന്നില്ല. ഇൻസ്റ്റാളേഷൻ പൂർത്തിയായ ശേഷം, അത് ഇൻസ്റ്റാൾ ചെയ്ത കോഡ് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുന്നു.

ഉദാഹരണത്തിന്, ഇത് ഒരു Express ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കുകയും സെർവർ പ്രതീക്ഷിച്ച പോർട്ടിൽ ലിസൺ ചെയ്യുന്നുണ്ടെന്ന് ഉറപ്പുവരുത്തുകയും ചെയ്യുന്നു. കോഡ് പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, ബെഞ്ച്മാർക്ക് പരാജയപ്പെടുന്നു. ഈ സ്മോക്ക് ടെസ്റ്റ് (smoke test) ഈ സ്യൂട്ടിനെ വെറുമൊരു മത്സരത്തിൽ നിന്ന് ഒരു ഓഡിറ്റാക്കി മാറ്റുന്നു. വേഗതയ്ക്ക് മാത്രം ഉത്തരം നൽകാൻ കഴിയാത്ത ഒരു ചോദ്യത്തിന് ഇത് ഉത്തരം നൽകുന്നു: ഇൻസ്റ്റാളേഷൻ യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നുണ്ടോ?

ഒരു സവിശേഷതയായി തീവ്രമായ സത്യസന്ധത

മിക്ക ബെഞ്ച്മാർക്ക് എഴുത്തുകാരും ഐച്ഛികമായി (optional) കാണുന്ന മൂന്ന് നിയമങ്ങൾ കാനറിയുടെ സ്രഷ്ടാവ് ഈ പ്രക്രിയയിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്.

ഒരേ കളിക്കളം (Same playing field). വിവിധ ടൂളുകളിലെ പ്രവർത്തനങ്ങളെ ഏകീകരിക്കുന്നതിന് ഫ്ലാഗുകൾ (flags) ഉപയോഗിക്കുന്നു. ഒരു പാക്കേജ് മാനേജർ അതിന്റെ ഡിഫോൾട്ട് സെറ്റിംഗുകൾ ഉപയോഗിച്ച് പ്രകടനത്തിലെ പോരായ്മകൾ മറച്ചുവെച്ചാൽ, ആ ടൂൾ അവിചാരിതമായി മികച്ചതായി തോന്നുന്നതിന് പകരം ബെഞ്ച്മാർക്ക് അത് തുറന്നുകാട്ടുന്നു.

യഥാർത്ഥ കോൾഡ് സ്റ്റാർട്ടുകൾ (Genuine cold starts). ആദ്യത്തേത് മാത്രമല്ല, ഓരോ തവണ ആവർത്തിക്കുമ്പോഴും npm cache-ഉം pnpm store-ഉം ക്ലിയർ ചെയ്യപ്പെടുന്നു. ആ "ഓരോ തവണ" (every) എന്ന വാക്കിന് വലിയ പ്രാധാന്യമുണ്ട്. പല ബെഞ്ച്മാർക്കുകളും ഒരിക്കൽ മാത്രം കാഷെ ക്ലിയർ ചെയ്യുകയും പിന്നീട് തുടർച്ചയായി അഞ്ച് ഇൻസ്റ്റാളേഷനുകൾ നടത്തുകയും ചെയ്യുന്നു. രണ്ടാമത് മുതൽ അഞ്ചാമത് വരെയുള്ള റണ്ണുകൾ യഥാർത്ഥത്തിൽ 'കോൾഡ്' അല്ല, അതിനാൽ കണക്കുകൾ അമിതമായി കാണപ്പെടാൻ സാധ്യതയുണ്ട്. എന്നാൽ കാനറി ഓരോ തവണയും പൂജ്യത്തിൽ നിന്നാണ് തുടങ്ങുന്നത്.

പരസ്യമായ പരാജയ അവസ്ഥകൾ (Public failure states). ഒരു പുതിയ റിലീസ് എന്തെങ്കിലും തകരാറുകൾ ഉണ്ടാക്കിയാൽ, റെപ്പോസിറ്ററി ചുവപ്പ് നിറത്തിലുള്ള പരാജയ അവസ്ഥയിൽ തന്നെ തുടരും. ഒരു പരിഹാരം വരുന്നത് വരെ അത് ഫ്രണ്ട് പേജിൽ തന്നെ പരിഹരിക്കപ്പെടാത്ത അവസ്ഥയിൽ കാണപ്പെടും. ഡാഷ്‌ബോർഡ് എപ്പോഴും പച്ച നിറത്തിൽ കാണിക്കാനായി പരാജയങ്ങൾ മറച്ചുവെക്കാൻ ഇവിടെ പാടില്ല. ഈ നയം സുതാര്യത ഉറപ്പാക്കുന്നു. ടൂളുകൾ വിലയിരുത്തുന്ന ഒരു ഉപയോക്താവിന് ഏതാണ് ഏറ്റവും വേഗതയേറിയത് എന്ന് മാത്രമല്ല, കാലക്രമേണ ഏതാണ് കൂടുതൽ വിശ്വസനീയമായി തുടരുന്നത് എന്നും കാണാൻ കഴിയും.

പരിശോധന അനിവാര്യമാണ് (Inspectability Is Non-Negotiable)

നിങ്ങൾക്ക് വീണ്ടും നിർമ്മിക്കാൻ (reproduce) കഴിയാത്ത ഒരു ബെഞ്ച്മാർക്ക് എന്നത് വെറുമൊരു പ്രചാരണ മുദ്രാവാക്യം മാത്രമാണ്. സ്യൂട്ടിന്റെ ഏതൊരു ഭാഗവും പ്രാദേശികമായി (locally) പ്രവർത്തിപ്പിക്കാൻ സഹായിക്കുന്ന ഒരു സിംഗിൾ ബാഷ് സ്ക്രിപ്റ്റിലൂടെ (bash script) കാനറി ഈ പ്രശ്നം പരിഹരിക്കുന്നു. ഒരു ക്ലൗഡ് പ്രൊവൈഡറുടെ നെറ്റ്‌വർക്കിംഗോ അല്ലെങ്കിൽ ഒരു മെയിന്റൈനറുടെ കൈകൊണ്ട് ക്രമീകരിച്ച എൻവയോൺമെന്റോ നിങ്ങൾ വിശ്വസിക്കേണ്ടതില്ല. കണക്കുകളിൽ എന്തെങ്കിലും വ്യത്യാസമുണ്ടെന്ന് നിങ്ങൾക്ക് സംശയമുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് സ്വന്തമായി കണക്കുകൾ ഉണ്ടാക്കാം.

ആ സുതാര്യത ഈ പ്രോജക്റ്റിനെ മെയിന്റൈനർമാർക്കും പ്രയോജനപ്രദമാക്കുന്നു. ഒരു റഗ്രഷൻ (regression) ഉണ്ടാകുമ്പോൾ, ഒരു ഡൗൺസ്ട്രീം ഡെവലപ്പർക്ക് സ്ക്രിപ്റ്റ് എടുത്ത് ടൂളിന്റെ റിലീസുകൾ bisect ചെയ്യാനും അപ്പസ്ട്രീം ടീമിന് ഒരു